services/work/src · flagon-io/g1t

coordinationA session g1t starts on Claude Managed Agents acts as g1t for the person who started it: on flagon-io/demo #1 the session closed the issue and the timeline said "syntaqx closed this as completed", because its token was a plain personal access token for @syntaqx (create_access_token, scoped to the repository), so every comment, close, review and pull request it made read as theirs. It now holds a run credential of a new kind, session (credentials::RunCredentialKind::Session, made by identity's create_run_credential, up to 12 hours, revoked when the session ends as before): it resolves to g1t on behalf of the person, may use every API and MCP operation credentials::SESSION_SCOPES allow (the scopes the old token had) and never one in NEVER, in its repository only, with the person's role there capped at Write, and pushes with git to that repository (any branch, so a new repository's first version still goes to its default branch) and to the working copies of its pull requests (decide_git_at, resolved by repos from the fork's source). Past the API and git it is the person with acting kept (as_person), so the session, its claims, its pull requests' forks and its pushes stay theirs and their role decides, while what it writes is recorded as g1t's for them: issues and pull requests it opens are g1t's, requested by them (work::authorship), and its comments, reviews and the events it notes (close, reopen, labels, assignees, milestones, blocked-by, ready, draft) are written as g1t with acting_for the person (work rows::By, into the acting_for columns of migration 0033), shown as "g1t ... on behalf of @syntaqx" on the issue and pull request pages; the person can still edit them, and a session's approval counts only where agents' approvals do. The system prompt says the token is g1t's for that person. The sessions guide and the identity architecture page say what a session acts as. Deploy order: every Worker that reads a viewer (api, repos, work, packages, events, identity and the rest) before integrations, which is the only one that makes the new kind; no migration. Checked: cargo test -p g1t-contracts (316) -p g1t-work (201) -p g1t-identity (183) -p g1t-integrations (76) -p g1t-repos (363) -p g1t-api (209) -p g1t-packages (112); cargo check --target wasm32-unknown-unknown of g1t-work, g1t-identity, g1t-integrations, g1t-repos, g1t-api, g1t-packages; apps/web tsc -b shows no errors in components/work.tsx (the rest need typegen).yesterday

authored.rsOnly projects have descriptions now; a repository no longer keeps one of its own (#45 ). Every repository already had a project of its own name, which showed the repository's description until it was given another, so the same line lived in two places with two settings pages. Now:yesterday

automerge.rsMerge branch 'worktree-agent-aa8485640dce3cc93' into ship-batchyesterday

checks.rsMerge branch 'worktree-agent-ac950b9c891220ad3'3d ago

closing.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issues2d ago

codeowners.rsMerge branch 'worktree-agent-ac2922d9eb84a7909'yesterday

commit_checks.rsMerge main into rm-agents: mirroring removal, open signups, free-tier limits, the g1t CLI and runner fixes, with the agent removal kept. The CLI's table of operations is regenerated from the API without the agent, customize and AI credit operations; no CLI command used them.4d ago

commit_comments.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issues2d ago

contributions.rsCards you act on in chat; agents comment and review as themselves; names shown cleanly; commits on the calendar1w ago

decisions.rsAgents in any harness coordinate through one inbox, the merge queue lands only what an attempt itself tested, and workspaces have Insights. Each session keeps the coordination updates that concern it (session_updates, migration 0038): claims, releases, hand-offs and expiries, overlaps, dependency changes, decisions, integration results and sessions starting and ending, about the issues and pull requests it is on or tied to, or every one while it is on nothing yet; never its own start, end or claims. An update is written in the same batch as the change it announces, guarded so it exists only once the change is made, with an id derived from the change, so a retry or two requests at once deliver it once; a blocker clearing and queue results follow their change under a key that names it. get_session's `updates` lists up to 100, oldest first, and reading never clears them; record_session_entries' `acknowledge` clears exact IDs for that session only and says how many were its (`acknowledged`). The CLI has `g1t session updates` and `g1t session acknowledge ID --note` (the decision note and the acknowledgement in one idempotent call, `--session` over G1T_SESSION), and those and `heartbeat` say which files the working copy changed (git status; G1T_TOUCH=0 turns it off), so overlapping edits are noticed whichever harness makes them; a pair of sessions is told again when another file in common joins. The Claude Code hooks fetch the inbox in the background, show it at every prompt and before tools when it changes or every two minutes, refresh after an acknowledgement, and never acknowledge. The AGENTS.md snippet, the skills, MCP's instructions and llms.txt say the same steps for every harness: scope claims (Scope, Interfaces, Depends on, Checks), proceed on complementary work, agree ownership before overlapping edits, record public summaries and evidence, never private reasoning. Claims resolve ownership in one statement, so simultaneous claims by one session converge. The merge queue: every attempt has its own id and branch (0037); a claimed build, an accepted build, a report and a callback each check their attempt; a dispatch registers its runs first and Actions fails the dispatch when it cannot; an attempt is decided only by its own runs (and other tools' statuses set after it was claimed), never an earlier attempt's or the pull request's own on the same commit (0040 keeps what it built and how many runs it registered); landing re-reads the rules, honours a bypass asked for when queued (0039), checks no predecessor remains, carries the exact tested commit to Git's compare-and-swap, records publication intent that fences removal, closing, drafting and changing base, resumes after a crash, and a publisher that lost a race no longer undoes the winner's landing; a retried attempt's branch is deleted; an entry whose branch or pull request is gone leaves the queue with a note instead of blocking those behind it; diagnosis rebuilds exactly what was tested and names a failing combination, not a proven cause. A session's page shows what awaits its agent as the coordination feed does. Workspace Insights (/:owner/-/insights): delivery metrics across a workspace's readable repositories (work service delivery_insights). Deploy Work migrations 0037 to 0040 first (the pipeline does), then Repos and Actions before Work, and the site with Work. Checked: cargo test for g1t-work (143), g1t-repos (311), g1t-actions-service (108), g1t-api (201), g1t (149), g1t-rules (72), g1t-contracts (306) and wasm32 builds; cargo check --workspace; the conformance suite against freshly built API and Work Workers (5, none skipped); the Claude Code hooks (49); the site's typecheck, tests (919) and a production build; the deploy tool's 92 tests; the docs build; and two unscripted local rehearsals in which two concurrent agents, given only a task and AGENTS.md, found each other, agreed a split and made complementary edits.2d ago

ghost.rsMerge branch 'main' of https://g1t.sh/flagon-io/g1tyesterday

guardrails.rsMerge branch 'worktree-agent-a4babc5b5815f6f3a'3d ago

head_repo.rsOnly projects have descriptions now; a repository no longer keeps one of its own (#45 ). Every repository already had a project of its own name, which showed the repository's description until it was given another, so the same line lived in two places with two settings pages. Now:yesterday

inbox.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issues2d ago

insights.rsAgents in any harness coordinate through one inbox, the merge queue lands only what an attempt itself tested, and workspaces have Insights. Each session keeps the coordination updates that concern it (session_updates, migration 0038): claims, releases, hand-offs and expiries, overlaps, dependency changes, decisions, integration results and sessions starting and ending, about the issues and pull requests it is on or tied to, or every one while it is on nothing yet; never its own start, end or claims. An update is written in the same batch as the change it announces, guarded so it exists only once the change is made, with an id derived from the change, so a retry or two requests at once deliver it once; a blocker clearing and queue results follow their change under a key that names it. get_session's `updates` lists up to 100, oldest first, and reading never clears them; record_session_entries' `acknowledge` clears exact IDs for that session only and says how many were its (`acknowledged`). The CLI has `g1t session updates` and `g1t session acknowledge ID --note` (the decision note and the acknowledgement in one idempotent call, `--session` over G1T_SESSION), and those and `heartbeat` say which files the working copy changed (git status; G1T_TOUCH=0 turns it off), so overlapping edits are noticed whichever harness makes them; a pair of sessions is told again when another file in common joins. The Claude Code hooks fetch the inbox in the background, show it at every prompt and before tools when it changes or every two minutes, refresh after an acknowledgement, and never acknowledge. The AGENTS.md snippet, the skills, MCP's instructions and llms.txt say the same steps for every harness: scope claims (Scope, Interfaces, Depends on, Checks), proceed on complementary work, agree ownership before overlapping edits, record public summaries and evidence, never private reasoning. Claims resolve ownership in one statement, so simultaneous claims by one session converge. The merge queue: every attempt has its own id and branch (0037); a claimed build, an accepted build, a report and a callback each check their attempt; a dispatch registers its runs first and Actions fails the dispatch when it cannot; an attempt is decided only by its own runs (and other tools' statuses set after it was claimed), never an earlier attempt's or the pull request's own on the same commit (0040 keeps what it built and how many runs it registered); landing re-reads the rules, honours a bypass asked for when queued (0039), checks no predecessor remains, carries the exact tested commit to Git's compare-and-swap, records publication intent that fences removal, closing, drafting and changing base, resumes after a crash, and a publisher that lost a race no longer undoes the winner's landing; a retried attempt's branch is deleted; an entry whose branch or pull request is gone leaves the queue with a note instead of blocking those behind it; diagnosis rebuilds exactly what was tested and names a failing combination, not a proven cause. A session's page shows what awaits its agent as the coordination feed does. Workspace Insights (/:owner/-/insights): delivery metrics across a workspace's readable repositories (work service delivery_insights). Deploy Work migrations 0037 to 0040 first (the pipeline does), then Repos and Actions before Work, and the site with Work. Checked: cargo test for g1t-work (143), g1t-repos (311), g1t-actions-service (108), g1t-api (201), g1t (149), g1t-rules (72), g1t-contracts (306) and wasm32 builds; cargo check --workspace; the conformance suite against freshly built API and Work Workers (5, none skipped); the Claude Code hooks (49); the site's typecheck, tests (919) and a production build; the deploy tool's 92 tests; the docs build; and two unscripted local rehearsals in which two concurrent agents, given only a task and AGENTS.md, found each other, agreed a split and made complementary edits.2d ago

insights.sqlAgents in any harness coordinate through one inbox, the merge queue lands only what an attempt itself tested, and workspaces have Insights. Each session keeps the coordination updates that concern it (session_updates, migration 0038): claims, releases, hand-offs and expiries, overlaps, dependency changes, decisions, integration results and sessions starting and ending, about the issues and pull requests it is on or tied to, or every one while it is on nothing yet; never its own start, end or claims. An update is written in the same batch as the change it announces, guarded so it exists only once the change is made, with an id derived from the change, so a retry or two requests at once deliver it once; a blocker clearing and queue results follow their change under a key that names it. get_session's `updates` lists up to 100, oldest first, and reading never clears them; record_session_entries' `acknowledge` clears exact IDs for that session only and says how many were its (`acknowledged`). The CLI has `g1t session updates` and `g1t session acknowledge ID --note` (the decision note and the acknowledgement in one idempotent call, `--session` over G1T_SESSION), and those and `heartbeat` say which files the working copy changed (git status; G1T_TOUCH=0 turns it off), so overlapping edits are noticed whichever harness makes them; a pair of sessions is told again when another file in common joins. The Claude Code hooks fetch the inbox in the background, show it at every prompt and before tools when it changes or every two minutes, refresh after an acknowledgement, and never acknowledge. The AGENTS.md snippet, the skills, MCP's instructions and llms.txt say the same steps for every harness: scope claims (Scope, Interfaces, Depends on, Checks), proceed on complementary work, agree ownership before overlapping edits, record public summaries and evidence, never private reasoning. Claims resolve ownership in one statement, so simultaneous claims by one session converge. The merge queue: every attempt has its own id and branch (0037); a claimed build, an accepted build, a report and a callback each check their attempt; a dispatch registers its runs first and Actions fails the dispatch when it cannot; an attempt is decided only by its own runs (and other tools' statuses set after it was claimed), never an earlier attempt's or the pull request's own on the same commit (0040 keeps what it built and how many runs it registered); landing re-reads the rules, honours a bypass asked for when queued (0039), checks no predecessor remains, carries the exact tested commit to Git's compare-and-swap, records publication intent that fences removal, closing, drafting and changing base, resumes after a crash, and a publisher that lost a race no longer undoes the winner's landing; a retried attempt's branch is deleted; an entry whose branch or pull request is gone leaves the queue with a note instead of blocking those behind it; diagnosis rebuilds exactly what was tested and names a failing combination, not a proven cause. A session's page shows what awaits its agent as the coordination feed does. Workspace Insights (/:owner/-/insights): delivery metrics across a workspace's readable repositories (work service delivery_insights). Deploy Work migrations 0037 to 0040 first (the pipeline does), then Repos and Actions before Work, and the site with Work. Checked: cargo test for g1t-work (143), g1t-repos (311), g1t-actions-service (108), g1t-api (201), g1t (149), g1t-rules (72), g1t-contracts (306) and wasm32 builds; cargo check --workspace; the conformance suite against freshly built API and Work Workers (5, none skipped); the Claude Code hooks (49); the site's typecheck, tests (919) and a production build; the deploy tool's 92 tests; the docs build; and two unscripted local rehearsals in which two concurrent agents, given only a task and AGENTS.md, found each other, agreed a split and made complementary edits.2d ago

integration.rsMerge commit '9232a85b'2d ago

labels.rsA session g1t starts on Claude Managed Agents acts as g1t for the person who started it: on flagon-io/demo #1 the session closed the issue and the timeline said "syntaqx closed this as completed", because its token was a plain personal access token for @syntaqx (create_access_token, scoped to the repository), so every comment, close, review and pull request it made read as theirs. It now holds a run credential of a new kind, session (credentials::RunCredentialKind::Session, made by identity's create_run_credential, up to 12 hours, revoked when the session ends as before): it resolves to g1t on behalf of the person, may use every API and MCP operation credentials::SESSION_SCOPES allow (the scopes the old token had) and never one in NEVER, in its repository only, with the person's role there capped at Write, and pushes with git to that repository (any branch, so a new repository's first version still goes to its default branch) and to the working copies of its pull requests (decide_git_at, resolved by repos from the fork's source). Past the API and git it is the person with acting kept (as_person), so the session, its claims, its pull requests' forks and its pushes stay theirs and their role decides, while what it writes is recorded as g1t's for them: issues and pull requests it opens are g1t's, requested by them (work::authorship), and its comments, reviews and the events it notes (close, reopen, labels, assignees, milestones, blocked-by, ready, draft) are written as g1t with acting_for the person (work rows::By, into the acting_for columns of migration 0033), shown as "g1t ... on behalf of @syntaqx" on the issue and pull request pages; the person can still edit them, and a session's approval counts only where agents' approvals do. The system prompt says the token is g1t's for that person. The sessions guide and the identity architecture page say what a session acts as. Deploy order: every Worker that reads a viewer (api, repos, work, packages, events, identity and the rest) before integrations, which is the only one that makes the new kind; no migration. Checked: cargo test -p g1t-contracts (316) -p g1t-work (201) -p g1t-identity (183) -p g1t-integrations (76) -p g1t-repos (363) -p g1t-api (209) -p g1t-packages (112); cargo check --target wasm32-unknown-unknown of g1t-work, g1t-identity, g1t-integrations, g1t-repos, g1t-api, g1t-packages; apps/web tsc -b shows no errors in components/work.tsx (the rest need typegen).yesterday

lib.rsWhat a session's push closes is g1t's, for the person: on flagon-io/session-lab #1 the session g1t started pushed its first version with Closes #1 , and the issue closed as it should, but its timeline said "syntaqx closed this in 20d5574 via session …", because the git.push event carries only the pusher's id (the person, for a session's token), so work wrote the close as theirs. repos now says on git.push which agent pushed for the person (GitPush::agent, from the viewer's acting, on HTTPS pushes, landings and pushes made on g1t), and work writes the close note as g1t with acting_for the pusher when it is set; a close through the API keeps following its caller (rows::By). Deploy: repos and work together. Checked: cargo test -p g1t-contracts (316) -p g1t-repos (364) -p g1t-work (203); wasm32 check of g1t-repos and g1t-work.yesterday

lifecycle.rsWork's merge_gate is gone: nothing called it once showing a pull request took the gate with what it already knows (merge_gate_seen, 6e24edf2), and the compiler said so on every build. Merging and the queue use merge_gate_by and queue_landing_gate as before; the comments that named merge_gate name those now. Checked: cargo test -p g1t-work (193 passing).yesterday

merge_message.rsMerge branch 'worktree-agent-a57a81856918d70a7' into ship-batchyesterday

mergeability.rsMerge branch 'worktree-agent-a57a81856918d70a7' into ship-batchyesterday

merging.rsOnly projects have descriptions now; a repository no longer keeps one of its own (#45 ). Every repository already had a project of its own name, which showed the repository's description until it was given another, so the same line lived in two places with two settings pages. Now:yesterday

milestones.rsA session g1t starts on Claude Managed Agents acts as g1t for the person who started it: on flagon-io/demo #1 the session closed the issue and the timeline said "syntaqx closed this as completed", because its token was a plain personal access token for @syntaqx (create_access_token, scoped to the repository), so every comment, close, review and pull request it made read as theirs. It now holds a run credential of a new kind, session (credentials::RunCredentialKind::Session, made by identity's create_run_credential, up to 12 hours, revoked when the session ends as before): it resolves to g1t on behalf of the person, may use every API and MCP operation credentials::SESSION_SCOPES allow (the scopes the old token had) and never one in NEVER, in its repository only, with the person's role there capped at Write, and pushes with git to that repository (any branch, so a new repository's first version still goes to its default branch) and to the working copies of its pull requests (decide_git_at, resolved by repos from the fork's source). Past the API and git it is the person with acting kept (as_person), so the session, its claims, its pull requests' forks and its pushes stay theirs and their role decides, while what it writes is recorded as g1t's for them: issues and pull requests it opens are g1t's, requested by them (work::authorship), and its comments, reviews and the events it notes (close, reopen, labels, assignees, milestones, blocked-by, ready, draft) are written as g1t with acting_for the person (work rows::By, into the acting_for columns of migration 0033), shown as "g1t ... on behalf of @syntaqx" on the issue and pull request pages; the person can still edit them, and a session's approval counts only where agents' approvals do. The system prompt says the token is g1t's for that person. The sessions guide and the identity architecture page say what a session acts as. Deploy order: every Worker that reads a viewer (api, repos, work, packages, events, identity and the rest) before integrations, which is the only one that makes the new kind; no migration. Checked: cargo test -p g1t-contracts (316) -p g1t-work (201) -p g1t-identity (183) -p g1t-integrations (76) -p g1t-repos (363) -p g1t-api (209) -p g1t-packages (112); cargo check --target wasm32-unknown-unknown of g1t-work, g1t-identity, g1t-integrations, g1t-repos, g1t-api, g1t-packages; apps/web tsc -b shows no errors in components/work.tsx (the rest need typegen).yesterday

prefetch.rsMerge branch 'main' of https://g1t.sh/flagon-io/g1tyesterday

pushed.rsWhat a session's push closes is g1t's, for the person: on flagon-io/session-lab #1 the session g1t started pushed its first version with Closes #1 , and the issue closed as it should, but its timeline said "syntaqx closed this in 20d5574 via session …", because the git.push event carries only the pusher's id (the person, for a session's token), so work wrote the close as theirs. repos now says on git.push which agent pushed for the person (GitPush::agent, from the viewer's acting, on HTTPS pushes, landings and pushes made on g1t), and work writes the close note as g1t with acting_for the pusher when it is set; a close through the API keeps following its caller (rows::By). Deploy: repos and work together. Checked: cargo test -p g1t-contracts (316) -p g1t-repos (364) -p g1t-work (203); wasm32 check of g1t-repos and g1t-work.yesterday

queue.rsMerge main into project-descriptionsyesterday

queue_tests.rsMerge commit '9232a85b'2d ago

reactions.rsMerge branch 'main' of https://g1t.sh/flagon-io/g1tyesterday

retired.rsOnly projects have descriptions now; a repository no longer keeps one of its own (#45 ). Every repository already had a project of its own name, which showed the repository's description until it was given another, so the same line lived in two places with two settings pages. Now:yesterday

reviews.rsA pull request's page no longer waits for its merge options. The loader awaited work's merge_choices beside everything else, and that call reads the branch's commits for the default merge messages (repos inspect_commits fetches and reads a pack from the git store every time) and asked repos whether it is behind: 6 to 10 seconds for flagon-io/g1t #39 and #41 (Server-Timing: work 9 calls, 7.5 s inside, 214 ms of it the database), long enough for the page to time out. Now the merge box opens on what the repository's settings allow, as it did when the service could not answer, and takes the service's choices, with their messages, in place when they stream in (useArrived), keeping the method picked and a dialog that is open. Merge options are asked for only for an open or draft pull request; a merged or closed one never needed them. In work, merge_choices takes whether it is behind from what was stored with its mergeability for its head as it is now, as get_pull does (behind_now, else repos), beside its settings rather than after them. Checked: cargo test for g1t-work (189), the site's typecheck and unit tests (934).yesterday

rows.rsA session g1t starts on Claude Managed Agents acts as g1t for the person who started it: on flagon-io/demo #1 the session closed the issue and the timeline said "syntaqx closed this as completed", because its token was a plain personal access token for @syntaqx (create_access_token, scoped to the repository), so every comment, close, review and pull request it made read as theirs. It now holds a run credential of a new kind, session (credentials::RunCredentialKind::Session, made by identity's create_run_credential, up to 12 hours, revoked when the session ends as before): it resolves to g1t on behalf of the person, may use every API and MCP operation credentials::SESSION_SCOPES allow (the scopes the old token had) and never one in NEVER, in its repository only, with the person's role there capped at Write, and pushes with git to that repository (any branch, so a new repository's first version still goes to its default branch) and to the working copies of its pull requests (decide_git_at, resolved by repos from the fork's source). Past the API and git it is the person with acting kept (as_person), so the session, its claims, its pull requests' forks and its pushes stay theirs and their role decides, while what it writes is recorded as g1t's for them: issues and pull requests it opens are g1t's, requested by them (work::authorship), and its comments, reviews and the events it notes (close, reopen, labels, assignees, milestones, blocked-by, ready, draft) are written as g1t with acting_for the person (work rows::By, into the acting_for columns of migration 0033), shown as "g1t ... on behalf of @syntaqx" on the issue and pull request pages; the person can still edit them, and a session's approval counts only where agents' approvals do. The system prompt says the token is g1t's for that person. The sessions guide and the identity architecture page say what a session acts as. Deploy order: every Worker that reads a viewer (api, repos, work, packages, events, identity and the rest) before integrations, which is the only one that makes the new kind; no migration. Checked: cargo test -p g1t-contracts (316) -p g1t-work (201) -p g1t-identity (183) -p g1t-integrations (76) -p g1t-repos (363) -p g1t-api (209) -p g1t-packages (112); cargo check --target wasm32-unknown-unknown of g1t-work, g1t-identity, g1t-integrations, g1t-repos, g1t-api, g1t-packages; apps/web tsc -b shows no errors in components/work.tsx (the rest need typegen).yesterday

rulesets.rsOnly projects have descriptions now; a repository no longer keeps one of its own (#45 ). Every repository already had a project of its own name, which showed the repository's description until it was given another, so the same line lived in two places with two settings pages. Now:yesterday

runs.rsMerge branch 'worktree-agent-a4babc5b5815f6f3a'3d ago

settings.rsWork's merge_gate is gone: nothing called it once showing a pull request took the gate with what it already knows (merge_gate_seen, 6e24edf2), and the compiler said so on every build. Merging and the queue use merge_gate_by and queue_landing_gate as before; the comments that named merge_gate name those now. Checked: cargo test -p g1t-work (193 passing).yesterday

statuses.rsMerge commit '9232a85b'2d ago

team_reviews.rsMerge branch 'worktree-agent-a3abfcce648e87dca'1w ago