whoami
ChatGPTReturns the authenticated Larridin user and organization context, plus devxAccess: admin (whole org), manager (own org-chart subtree), grant (aggregate-only reporting grant) or none (no DevX data). aiAccess: admin (whole org), manager (own reporting line for team and person views), member (company-wide aggregates only) or none (no company-wide AI tools).
work_add_observation
ChatGPTWork context for ameya@larridin-dev.com, derived from their own captured work activity (browser + desktop), own data only. Start with work_get_context for the summary, then drill in with work_get_thread / work_explain_status / work_get_evidence. Every status carries a basis: observed (seen in captures), inferred (code rule, e.g. idle timeout) or unverified (completion would happen somewhere we don't capture). 'unverified' means CHECK, not 'still owed'. Next actions are typed: do (passed the task gate) | check_status (verify before acting) | none. If you (the assistant) learn something from the user's own mail/calendar that the captures missed (e.g. someone else submitted the work), tell the user; call work_add_observation only once they confirm, so the status flips everywhere. Record evidence missing from captures, only when the user asks for it or confirms it. Status, action, and views are immediately re-derived.
work_explain_status
ChatGPTWork context for ameya@larridin-dev.com, derived from their own captured work activity (browser + desktop), own data only. Start with work_get_context for the summary, then drill in with work_get_thread / work_explain_status / work_get_evidence. Every status carries a basis: observed (seen in captures), inferred (code rule, e.g. idle timeout) or unverified (completion would happen somewhere we don't capture). 'unverified' means CHECK, not 'still owed'. Next actions are typed: do (passed the task gate) | check_status (verify before acting) | none. If you (the assistant) learn something from the user's own mail/calendar that the captures missed (e.g. someone else submitted the work), tell the user; call work_add_observation only once they confirm, so the status flips everywhere. Explain the status and next-action gates, the model proposal, and what evidence could change the result.
work_get_changes
ChatGPTWork context for ameya@larridin-dev.com, derived from their own captured work activity (browser + desktop), own data only. Start with work_get_context for the summary, then drill in with work_get_thread / work_explain_status / work_get_evidence. Every status carries a basis: observed (seen in captures), inferred (code rule, e.g. idle timeout) or unverified (completion would happen somewhere we don't capture). 'unverified' means CHECK, not 'still owed'. Next actions are typed: do (passed the task gate) | check_status (verify before acting) | none. If you (the assistant) learn something from the user's own mail/calendar that the captures missed (e.g. someone else submitted the work), tell the user; call work_add_observation only once they confirm, so the status flips everywhere. Compare daily snapshots for new threads, status transitions, blockers, next actions, and day summaries.
work_get_collaborator
ChatGPTWork context for ameya@larridin-dev.com, derived from their own captured work activity (browser + desktop), own data only. Start with work_get_context for the summary, then drill in with work_get_thread / work_explain_status / work_get_evidence. Every status carries a basis: observed (seen in captures), inferred (code rule, e.g. idle timeout) or unverified (completion would happen somewhere we don't capture). 'unverified' means CHECK, not 'still owed'. Next actions are typed: do (passed the task gate) | check_status (verify before acting) | none. If you (the assistant) learn something from the user's own mail/calendar that the captures missed (e.g. someone else submitted the work), tell the user; call work_add_observation only once they confirm, so the status flips everywhere. Find a collaborator by name or role and show their channels, days, and shared threads.
work_get_context
ChatGPTWork context for ameya@larridin-dev.com, derived from their own captured work activity (browser + desktop), own data only. Start with work_get_context for the summary, then drill in with work_get_thread / work_explain_status / work_get_evidence. Every status carries a basis: observed (seen in captures), inferred (code rule, e.g. idle timeout) or unverified (completion would happen somewhere we don't capture). 'unverified' means CHECK, not 'still owed'. Next actions are typed: do (passed the task gate) | check_status (verify before acting) | none. If you (the assistant) learn something from the user's own mail/calendar that the captures missed (e.g. someone else submitted the work), tell the user; call work_add_observation only once they confirm, so the status flips everywhere. Default entry point for every work question: call this first for priorities, projects, people, follow-ups, blockers, decisions or what to do next. It is an index, not the final answer: pick the relevant thread_ids and call work_get_thread, then verify ownership, completion and blockers with work_explain_status or work_get_evidence (pass latest_observation.observation_id) before recommending an action. Access-only checks need no drill-down. Returns the signed-in user's profile, day summary, top-of-mind threads, blockers, status checks, gated to-dos and recently resolved work; each thread card carries thread_id, status, status_basis, next_action, last_observed and latest_observation. Set as_of (YYYY-MM-DD) only for a historical snapshot.
work_get_day
ChatGPTWork context for ameya@larridin-dev.com, derived from their own captured work activity (browser + desktop), own data only. Start with work_get_context for the summary, then drill in with work_get_thread / work_explain_status / work_get_evidence. Every status carries a basis: observed (seen in captures), inferred (code rule, e.g. idle timeout) or unverified (completion would happen somewhere we don't capture). 'unverified' means CHECK, not 'still owed'. Next actions are typed: do (passed the task gate) | check_status (verify before acting) | none. If you (the assistant) learn something from the user's own mail/calendar that the captures missed (e.g. someone else submitted the work), tell the user; call work_add_observation only once they confirm, so the status flips everywhere. Get a day summary, observations grouped by thread, session count, and time by app.
work_get_evidence
ChatGPTWork context for ameya@larridin-dev.com, derived from their own captured work activity (browser + desktop), own data only. Start with work_get_context for the summary, then drill in with work_get_thread / work_explain_status / work_get_evidence. Every status carries a basis: observed (seen in captures), inferred (code rule, e.g. idle timeout) or unverified (completion would happen somewhere we don't capture). 'unverified' means CHECK, not 'still owed'. Next actions are typed: do (passed the task gate) | check_status (verify before acting) | none. If you (the assistant) learn something from the user's own mail/calendar that the captures missed (e.g. someone else submitted the work), tell the user; call work_add_observation only once they confirm, so the status flips everywhere. Get normalized captured sessions behind an observation or explicit session IDs. Captures contain no keystrokes or field values.
work_get_thread
ChatGPTWork context for ameya@larridin-dev.com, derived from their own captured work activity (browser + desktop), own data only. Start with work_get_context for the summary, then drill in with work_get_thread / work_explain_status / work_get_evidence. Every status carries a basis: observed (seen in captures), inferred (code rule, e.g. idle timeout) or unverified (completion would happen somewhere we don't capture). 'unverified' means CHECK, not 'still owed'. Next actions are typed: do (passed the task gate) | check_status (verify before acting) | none. If you (the assistant) learn something from the user's own mail/calendar that the captures missed (e.g. someone else submitted the work), tell the user; call work_add_observation only once they confirm, so the status flips everywhere. Get one thread. summary gives state and reasons; trail adds dated observations and evidence titles; evidence adds URLs and session IDs.
work_give_feedback
ChatGPTWork context for ameya@larridin-dev.com, derived from their own captured work activity (browser + desktop), own data only. Start with work_get_context for the summary, then drill in with work_get_thread / work_explain_status / work_get_evidence. Every status carries a basis: observed (seen in captures), inferred (code rule, e.g. idle timeout) or unverified (completion would happen somewhere we don't capture). 'unverified' means CHECK, not 'still owed'. Next actions are typed: do (passed the task gate) | check_status (verify before acting) | none. If you (the assistant) learn something from the user's own mail/calendar that the captures missed (e.g. someone else submitted the work), tell the user; call work_add_observation only once they confirm, so the status flips everywhere. Queue feedback about a wrong status, merge, title, noise, or other issue for review; it is not applied automatically.
work_list_threads
ChatGPTWork context for ameya@larridin-dev.com, derived from their own captured work activity (browser + desktop), own data only. Start with work_get_context for the summary, then drill in with work_get_thread / work_explain_status / work_get_evidence. Every status carries a basis: observed (seen in captures), inferred (code rule, e.g. idle timeout) or unverified (completion would happen somewhere we don't capture). 'unverified' means CHECK, not 'still owed'. Next actions are typed: do (passed the task gate) | check_status (verify before acting) | none. If you (the assistant) learn something from the user's own mail/calendar that the captures missed (e.g. someone else submitted the work), tell the user; call work_add_observation only once they confirm, so the status flips everywhere. List bounded thread cards with status, kind, recency, action, and archive filters.
work_search
ChatGPTWork context for ameya@larridin-dev.com, derived from their own captured work activity (browser + desktop), own data only. Start with work_get_context for the summary, then drill in with work_get_thread / work_explain_status / work_get_evidence. Every status carries a basis: observed (seen in captures), inferred (code rule, e.g. idle timeout) or unverified (completion would happen somewhere we don't capture). 'unverified' means CHECK, not 'still owed'. Next actions are typed: do (passed the task gate) | check_status (verify before acting) | none. If you (the assistant) learn something from the user's own mail/calendar that the captures missed (e.g. someone else submitted the work), tell the user; call work_add_observation only once they confirm, so the status flips everywhere. Find threads by PR number, document or meeting identifier, person, customer, title, summary, or observation text.
