services/work/src · flagon-io/g1t

coordinationMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issuesyesterday

authored.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issuesyesterday

automerge.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issuesyesterday

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

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

codeowners.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issuesyesterday

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.3d ago

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

contributions.rsCards you act on in chat; agents comment and review as themselves; names shown cleanly; commits on the calendar6d 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.yesterday

ghost.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issuesyesterday

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

head_repo.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issuesyesterday

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

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.yesterday

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.yesterday

integration.rsMerge commit '9232a85b'yesterday

labels.rsThe work, events, webhooks, actions, repos and packages services no longer run g1t's own agents. Work drops the 35 calls that queued issues for g1t, delegated them, messaged and reviewed through the agent, planned, captured memories automatically, rated confidence and capped agent spend, and its pull request lifecycle no longer revises or reviews: a pull request only advances to a merge by the repository's auto-merge setting. Merging a pull request that is behind now catches it up itself, through the repository's branch update, and lands it when the push arrives; when it can't be caught up cleanly the merge says to merge the base in and try again. Recording a session on a pull request, memory recall and remember, overlaps, the merge queue and required checks stay as they were.3d ago

lib.rsAn open pull request's page no longer asks repos whether it is behind a second time, and anyone's ready pull request says it is ready to merge. Signed in, flagon-io/g1t #41 took 5 to 10 seconds and once failed: get_pull worked out whether it is behind (stored with its mergeability for its head, as merge_choices does), then the merge gate asked repos `behind` again on every view, a walk of the git store that took up to 5 s (Workers Logs: /rpc/behind 4.9 s, 649 ms CPU). The gate now takes what the page already worked out (merge_gate_seen), as does the lifecycle's own gate; merging and the queue still ask repos as they did. And the lifecycle was worked out only for pull requests g1t's agent made (managed = 1), which since g1t stopped running agents of its own is none, so a person's pull request that met everything its branch asks for (#41 : CI passed, no approvals required) said nothing about being ready. Every open pull request now gets one; only one g1t manages merges by itself (auto_merge is gated on managed), and anyone else's draft still gets none, so its page does not keep refreshing. Lists keep showing a lifecycle only for managed pull requests, since nothing yet refreshes a stored one for the rest. Checked: cargo test -p g1t-work (189 passing).yesterday

lifecycle.rsAn open pull request's page no longer asks repos whether it is behind a second time, and anyone's ready pull request says it is ready to merge. Signed in, flagon-io/g1t #41 took 5 to 10 seconds and once failed: get_pull worked out whether it is behind (stored with its mergeability for its head, as merge_choices does), then the merge gate asked repos `behind` again on every view, a walk of the git store that took up to 5 s (Workers Logs: /rpc/behind 4.9 s, 649 ms CPU). The gate now takes what the page already worked out (merge_gate_seen), as does the lifecycle's own gate; merging and the queue still ask repos as they did. And the lifecycle was worked out only for pull requests g1t's agent made (managed = 1), which since g1t stopped running agents of its own is none, so a person's pull request that met everything its branch asks for (#41 : CI passed, no approvals required) said nothing about being ready. Every open pull request now gets one; only one g1t manages merges by itself (auto_merge is gated on managed), and anyone else's draft still gets none, so its page does not keep refreshing. Lists keep showing a lifecycle only for managed pull requests, since nothing yet refreshes a stored one for the rest. Checked: cargo test -p g1t-work (189 passing).yesterday

merge_message.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issuesyesterday

mergeability.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issuesyesterday

merging.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

milestones.rsTeams and CODEOWNERS, labels and milestones, dependency updates, the security suite, and a clearer top bar1w ago

prefetch.rsThe work, events, webhooks, actions, repos and packages services no longer run g1t's own agents. Work drops the 35 calls that queued issues for g1t, delegated them, messaged and reviewed through the agent, planned, captured memories automatically, rated confidence and capped agent spend, and its pull request lifecycle no longer revises or reviews: a pull request only advances to a merge by the repository's auto-merge setting. Merging a pull request that is behind now catches it up itself, through the repository's branch update, and lands it when the push arrives; when it can't be caught up cleanly the merge says to merge the base in and try again. Recording a session on a pull request, memory recall and remember, overlaps, the merge queue and required checks stay as they were.3d ago

queue.rsMerge commit '9232a85b'yesterday

queue_tests.rsMerge commit '9232a85b'yesterday

retired.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issuesyesterday

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.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issuesyesterday

rulesets.rsAn open pull request's page no longer asks repos whether it is behind a second time, and anyone's ready pull request says it is ready to merge. Signed in, flagon-io/g1t #41 took 5 to 10 seconds and once failed: get_pull worked out whether it is behind (stored with its mergeability for its head, as merge_choices does), then the merge gate asked repos `behind` again on every view, a walk of the git store that took up to 5 s (Workers Logs: /rpc/behind 4.9 s, 649 ms CPU). The gate now takes what the page already worked out (merge_gate_seen), as does the lifecycle's own gate; merging and the queue still ask repos as they did. And the lifecycle was worked out only for pull requests g1t's agent made (managed = 1), which since g1t stopped running agents of its own is none, so a person's pull request that met everything its branch asks for (#41 : CI passed, no approvals required) said nothing about being ready. Every open pull request now gets one; only one g1t manages merges by itself (auto_merge is gated on managed), and anyone else's draft still gets none, so its page does not keep refreshing. Lists keep showing a lifecycle only for managed pull requests, since nothing yet refreshes a stored one for the rest. Checked: cargo test -p g1t-work (189 passing).yesterday

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

settings.rsMerge branch 'forking': repository forking, pull request merge methods and every repository setting for pull requests, commits, pushes and issuesyesterday

statuses.rsMerge commit '9232a85b'yesterday

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