services/work/src · flagon-io/g1t

coordinationA session its harness left behind can be ended by hand from the site: under Live now, on a project's overview and the Work page, each session, active or idle, has a menu with End session for whoever runs it and for anyone with write access to the repository (nobody else sees it), and the session's page has an End session button for them; a confirm dialog says what happens and the list is read again once it has ended. It ends with end_reason "ended by hand by @name", its subagents still going end with it, and its claims stay until released or expired. end_session in the work service now lets someone with write (push) access end a session that is not theirs, recorded as ended by hand by them and without their reason or result (g1t_contracts::work::may_end_session and session_end_reason; EndSessionArgs takes by_hand, which the site's new endWorkSession sends); the Work feed reads such an end as "ended bo's session by hand". A session g1t runs on the workspace's Anthropic account is still stopped from its page. The API's end_session description, the OpenAPI copy and the sessions guide say so. Checked: cargo test -p g1t-contracts (321, new: who may end a session, the reason ended by hand), -p g1t-work (214), -p g1t-api (212, OpenAPI regenerated), -p g1t ops; cargo check -p g1t-integrations; apps/web tsc -b and node --test app/lib/coordination.test.ts (17, new: who may end one, the feed line). Not looked at in a browser.yesterday

attachments.rsAn agent can put an image in a pull request, an issue or a comment without committing it: on flagon-io/session-lab #2 a cloud session asked to show a screenshot of its preview in the pull request's description found no way to upload one (not in g1t --help, g1t api --list or the docs), so it committed the PNG, linked it at that commit and removed it in a second commit. The site has no comment-image upload either; images only ever came from repository files. Now upload_attachment (POST /repos/{owner}/{repo}/attachments, issues:write, the issue tool's attach action over MCP) takes name, data (the file base64-encoded, as upload_sarif takes its file) and an optional content_type, and answers in snake_case with id, name, url, markdown (![name](url), ready to paste), content_type and size. The work service decides, as add_comment does: a confirmed account that can read the repository, which is not archived. The type is read from the bytes (PNG, JPEG, GIF or WebP; a content_type that says otherwise is refused), at most 10 MB; too large is the new FailureCode too_large (413), another type the new unsupported_type (415), in Rust and TS contracts and the OpenAPI error codes. The bytes go in the usercontent namespace (AVATARS, now bound to work) under attachments/<id>, where the id is 256 random bits so the address is its permission, as Docs files' is; a row in the new attachments table (migration 0048) names the repository, and repo.purged deletes the bytes, then the rows. The usercontent origin serves /attachments/<id> as it serves avatars (stored type, nosniff, sandboxed). The API forms url from USERCONTENT_URL as the site does (g1tusercontent.com for g1t.sh, SITE_URL/-/usercontent elsewhere; the self-host config now passes it to the API). The CLI has g1t attach FILE... (prints each image's Markdown; --json the fields, a list for several) and --attach FILE (repeatable) on g1t issue create, issue comment, pr create, pr comment and pr ready, which uploads and appends the Markdown after the text. A session's run credential gets upload_attachment through issues:write, bound to its own repository (tested), and the cloud session's system prompt says to upload screenshots with g1t attach and never commit images just to link them. Docs: the CLI guide (Images in descriptions and comments), pull requests (Images), sessions, the MCP reference, self-hosting's USERCONTENT_URL row, reference.json and the regenerated openapi.json, CLI ops table and CLI reference. Deploy order: apply work migration 0048 and deploy work (new AVATARS binding), then the site (usercontent serves /attachments), then api, then integrations (prompt) and the docs; g1t attach and --attach ship with the next CLI release, which cloud sessions need before the prompt's advice works. Checked: cargo test -p g1t-contracts (319), -p g1t-work (209), -p g1t-api (211; openapi regenerated with G1T_WRITE_OPENAPI), -p g1t (112 + 51; ops_table and cli_reference regenerated with G1T_WRITE_OPS and G1T_WRITE_DOCS), -p g1t-integrations (76); cargo check -p g1t-api, -p g1t-work and -p g1t-integrations --target wasm32-unknown-unknown; node --test apps/web/app/lib/token-scopes.test.ts.2d ago

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:2d ago

automerge.rsMerge branch 'worktree-agent-aa8485640dce3cc93' into ship-batch2d ago

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'2d ago

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/g1t2d ago

guardrails.rsMerge branch 'worktree-agent-a4babc5b5815f6f3a'4d 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:2d ago

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).2d ago

lib.rsSessions show by who is looking, and nothing that looks like a credential is kept: on a public repository anyone could read every prompt, command and subagent report a session recorded (coordination_repo only asked whether they could read the repository). Now whoever ran a session sees all of it; a member of the workspace sees what it did (title, tool calls, messages, notes, skills, files, subagents) but not the prompts someone else typed nor a tool's output, which show as kept back (SessionEntry.withheld), and a title without swearing (soften); anyone else sees that it runs, who runs it, its harness, state and times and the issues and pull requests it is tied to, nothing it recorded, touched, was asked or reported, nor its title, branch or model (SessionDetail.limited). The same holds for lists (Live now, Work), a pull request's session (outsiders see only g1t's notes; prompts and tool output only to their author, by the session that recorded them) and its sessions list's prompt (members only). Pending updates are shaped too: an outsider's own session on a public repository hears of members' sessions without their titles, prompts, tasks, results, branches or models.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).2d ago

merge_message.rsMerge branch 'worktree-agent-a57a81856918d70a7' into ship-batch2d ago

mergeability.rsMerge branch 'worktree-agent-a57a81856918d70a7' into ship-batch2d ago

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:2d ago

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).2d ago

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

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

queue.rsMerge main into project-descriptions2d ago

queue_tests.rsMerge commit '9232a85b'2d ago

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

retired.rsAn agent can put an image in a pull request, an issue or a comment without committing it: on flagon-io/session-lab #2 a cloud session asked to show a screenshot of its preview in the pull request's description found no way to upload one (not in g1t --help, g1t api --list or the docs), so it committed the PNG, linked it at that commit and removed it in a second commit. The site has no comment-image upload either; images only ever came from repository files. Now upload_attachment (POST /repos/{owner}/{repo}/attachments, issues:write, the issue tool's attach action over MCP) takes name, data (the file base64-encoded, as upload_sarif takes its file) and an optional content_type, and answers in snake_case with id, name, url, markdown (![name](url), ready to paste), content_type and size. The work service decides, as add_comment does: a confirmed account that can read the repository, which is not archived. The type is read from the bytes (PNG, JPEG, GIF or WebP; a content_type that says otherwise is refused), at most 10 MB; too large is the new FailureCode too_large (413), another type the new unsupported_type (415), in Rust and TS contracts and the OpenAPI error codes. The bytes go in the usercontent namespace (AVATARS, now bound to work) under attachments/<id>, where the id is 256 random bits so the address is its permission, as Docs files' is; a row in the new attachments table (migration 0048) names the repository, and repo.purged deletes the bytes, then the rows. The usercontent origin serves /attachments/<id> as it serves avatars (stored type, nosniff, sandboxed). The API forms url from USERCONTENT_URL as the site does (g1tusercontent.com for g1t.sh, SITE_URL/-/usercontent elsewhere; the self-host config now passes it to the API). The CLI has g1t attach FILE... (prints each image's Markdown; --json the fields, a list for several) and --attach FILE (repeatable) on g1t issue create, issue comment, pr create, pr comment and pr ready, which uploads and appends the Markdown after the text. A session's run credential gets upload_attachment through issues:write, bound to its own repository (tested), and the cloud session's system prompt says to upload screenshots with g1t attach and never commit images just to link them. Docs: the CLI guide (Images in descriptions and comments), pull requests (Images), sessions, the MCP reference, self-hosting's USERCONTENT_URL row, reference.json and the regenerated openapi.json, CLI ops table and CLI reference. Deploy order: apply work migration 0048 and deploy work (new AVATARS binding), then the site (usercontent serves /attachments), then api, then integrations (prompt) and the docs; g1t attach and --attach ship with the next CLI release, which cloud sessions need before the prompt's advice works. Checked: cargo test -p g1t-contracts (319), -p g1t-work (209), -p g1t-api (211; openapi regenerated with G1T_WRITE_OPENAPI), -p g1t (112 + 51; ops_table and cli_reference regenerated with G1T_WRITE_OPS and G1T_WRITE_DOCS), -p g1t-integrations (76); cargo check -p g1t-api, -p g1t-work and -p g1t-integrations --target wasm32-unknown-unknown; node --test apps/web/app/lib/token-scopes.test.ts.2d ago

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).2d ago

rows.rsSessions show by who is looking, and nothing that looks like a credential is kept: on a public repository anyone could read every prompt, command and subagent report a session recorded (coordination_repo only asked whether they could read the repository). Now whoever ran a session sees all of it; a member of the workspace sees what it did (title, tool calls, messages, notes, skills, files, subagents) but not the prompts someone else typed nor a tool's output, which show as kept back (SessionEntry.withheld), and a title without swearing (soften); anyone else sees that it runs, who runs it, its harness, state and times and the issues and pull requests it is tied to, nothing it recorded, touched, was asked or reported, nor its title, branch or model (SessionDetail.limited). The same holds for lists (Live now, Work), a pull request's session (outsiders see only g1t's notes; prompts and tool output only to their author, by the session that recorded them) and its sessions list's prompt (members only). Pending updates are shaped too: an outsider's own session on a public repository hears of members' sessions without their titles, prompts, tasks, results, branches or models.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:2d ago

runs.rsSessions show by who is looking, and nothing that looks like a credential is kept: on a public repository anyone could read every prompt, command and subagent report a session recorded (coordination_repo only asked whether they could read the repository). Now whoever ran a session sees all of it; a member of the workspace sees what it did (title, tool calls, messages, notes, skills, files, subagents) but not the prompts someone else typed nor a tool's output, which show as kept back (SessionEntry.withheld), and a title without swearing (soften); anyone else sees that it runs, who runs it, its harness, state and times and the issues and pull requests it is tied to, nothing it recorded, touched, was asked or reported, nor its title, branch or model (SessionDetail.limited). The same holds for lists (Live now, Work), a pull request's session (outsiders see only g1t's notes; prompts and tool output only to their author, by the session that recorded them) and its sessions list's prompt (members only). Pending updates are shaped too: an outsider's own session on a public repository hears of members' sessions without their titles, prompts, tasks, results, branches or models.yesterday

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).2d ago

statuses.rsMerge commit '9232a85b'2d ago

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