apps/api/src · flagon-io/g1t

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

audit.rsMerge workspace aliases through Actions and tokens: uses: g1t/deploy@v1 resolves to flagon-io/deploy, a token scoped to a repository reaches it under the alias, a g1t/ action is never taken from GitHub, and the Actions release creates g1t's action repositories when they are missing.4d ago

billing.rsThe contracts no longer describe g1t's own agents, and workspaces can keep their AI providers. Every consumer had already stopped using them, so the TypeScript and Rust contracts drop the workspace-agent, ability, look, skill-library, context, runner-agent and mention modules, the chat and docs RPCs agents posted and read through, the folio agent methods, the agent_waiting notification, agent.asked and memory.changed events, AI credit, token and gateway billing types, model routes and sessions, team agents, agent tokens, plan, review, message and confidence types, command rules, cost caps and confidence rules. The agents:run and models:* scopes are no longer offered by any preset, OAuth default or permission form, but a stored token or grant that names them still reads; and the removed operations are gone from the scope table, so the API's check that every operation has exactly one scope is strict again. What stored data needs in order to parse (old run and credential kinds, an agent team lead, retired rules and webhook events, old guardrail and integration settings) still parses, and a run's token is still PrincipalKind::Agent, which now means a run's token and the @g1t rows written before. The customize, marketplace, skills and claude-plugin contracts stay only until the mobile app drops its Customize screens.3d ago

blobs.rsThe artifacts service is services/artifacts, the Worker g1t-artifacts, bound as ARTIFACTS by the API, the site and the agents; its live rooms move to it with a Durable Object transfer from g1t-docs-service, and its database, bucket, indexes and queue keep their names. The git store's binding and settings are GITSTORE, its ops scripts gitstore-*, and workflow run artifacts keep their compatible API under run_artifacts modules. The deploy tool puts a Worker that has never deployed before the Workers in its stage that bind to it, and the deploy guide gives the cutover runbook.6d ago

broker.rsMerge branch 'main' into rm-agents3d ago

caches.rsMerge branch 'worktree-agent-a3b9b1f730f55b5bf'3d ago

checks.rsMerge checks: statuses and check runs on every commit1w ago

commits.rsAsk names people by their g1t username, knows what shipped means, and picks its model by itself. Asked "What shipped today?", Ask made "@chasepierce" out of a commit's git author name, corrected itself mid-answer, and said nothing had reached production though the repository's own Deploy run had: commit listings carried only the git name, the prompt never said which field is a username, and activity counted only g1t.page deployments as production. Commits from list_commits now say `author: { name, username }`, the username from identity's address owners (a confirmed or noreply address; g1t's own are g1t), never the address, and activity's landed commits carry `username` too; the prompt mentions only usernames tools returned, never turns a git name or address into one, and answers once, without "wait" or corrections. Shipping, to Ask, is reaching the default branch and then production: a successful run of a repository's deploy workflow on its default branch (a workflow whose name or file says deploy, not preview) now counts as a production deployment beside g1t.page's, each landed commit says whether it is live (and by which deploy), deploying, failed or not deployed (a deploy carries everything before it on the branch), summary.shipped counts them, and list_runs takes since and until; releases and tags are one more signal, and today is the start of your day in your time zone. Ask's model is Auto by default (migration 0010 turns it on for every Ask route nobody chose a model for: the old picker started on the provider's first model, Haiku for Anthropic). Auto sends each question to a model of the workspace's provider without asking another model: a short lookup to a fast one, a question about why, how, what shipped, changes, failures, a time range, or a long conversation to a standard one; tiers come from the models' names, so it works for every provider, the largest only when nothing else is there, and an Azure deployment or an endpoint without a list keeps its own model. The answer says which ("Anthropic · Auto · claude-sonnet-5-5"); an explicit pick still wins. The Ask guide has Auto and what Ask means by shipped. Checked on this change alone (a worktree of the commit before it): cargo test for g1t-integrations (70, new: Auto's routing for each provider, prompt rules), g1t-api (204, new: commit authors with and without an account, shipped states), g1t-actions-service (108), g1t-contracts (306) and the CLI (149); cargo check --workspace; wasm32 builds of api, integrations and actions; the site's typecheck (tsc -b --force), its Ask tests and a production build; chat's tests and typecheck; the deploy tool's tests.yesterday

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

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

deploy_keys.rsMerge branch 'worktree-agent-a5a5de74d8863d554' into worktree-agent-a16631325aecf58ca1w ago

deployments.rsMerge GitHub pull request #8 (claude/cool-newton-7nm8r9): Docker deployments on g1t.page behind a switch that stays off until Cloudflare's container APIs are checked live, workflows a workspace manages in its repositories, tarball and zipball downloads, refs/pull/* kept to g1t alone, framework detection for g1t.page builds, and a workflow's event payload matching GitHub's.4d ago

folios.rsThe API and MCP server no longer offer g1t's own agents. g1t is what your coding agents work against, not an agent of its own, so the operations that drove hosted agents are gone: messaging an agent on a pull request (message_agent, take_messages, answer_message), assigning or delegating an issue to g1t (assign_issue, delegate), plans (plan_work, get_plan, apply_plan), the context hub (search_context, get_entity), model routes, agents' computers, AI Gateway requests, "Fix with g1t" on a security alert, and every Customize route (marketplaces, plugins, connectors). The callbacks the agent sandbox reported through (/agent-runs/*, /runs/:id/usage, /plans/:id, /reviews/:id) go with them, update_repo_settings stops accepting agent_review, max_revisions and hold_low_confidence, import_issue stops accepting assign, and an old agent token with no run behind it is refused.3d ago

follow.rsMerge branch 'worktree-agent-ad531323a21f4c975'3d ago

lib.rsMerge branch 'worktree-agent-ac7d6e0b40efe9fe8' into ship-batchyesterday

limits.rsMerge remote-tracking branch 'origin/claude/cool-newton-7nm8r9'4d ago

logs.rsMerge Actions runs: summaries, attempts and re-runs, graceful cancel, log downloads, badges (actions 0009)1w ago

mcp.rsAgents are told how a commit closes an issue: on flagon-io/g1t #47 the billing session pushed its work straight to main with commits ending "(#47 )", which only links the issue, so #47 stayed open after it shipped and was closed by hand. The plugin's SessionStart and subagent context (TRAILER in hooks/g1t.mjs), the work-on-issue skill's Finish step, the system prompt of sessions on Claude Managed Agents (for a repository's first commit) and the MCP server's instructions now say that a pull request's merge closes its issue, and a commit pushed straight to the default branch closes one only when its message says Closes #N (Fixes, Resolves), never with a bare (#N); the MCP instructions add that issue close with commit closes one after the fact. The Claude Code plugin guide says so. Deploy: api and integrations; the plugin ships with its next release. Checked: node --test of plugins/claude-code/test (56), cargo test -p g1t-api mcp (5), cargo test -p g1t-integrations agent_sessions (11).yesterday

notifications.rsThe contracts no longer describe g1t's own agents, and workspaces can keep their AI providers. Every consumer had already stopped using them, so the TypeScript and Rust contracts drop the workspace-agent, ability, look, skill-library, context, runner-agent and mention modules, the chat and docs RPCs agents posted and read through, the folio agent methods, the agent_waiting notification, agent.asked and memory.changed events, AI credit, token and gateway billing types, model routes and sessions, team agents, agent tokens, plan, review, message and confidence types, command rules, cost caps and confidence rules. The agents:run and models:* scopes are no longer offered by any preset, OAuth default or permission form, but a stored token or grant that names them still reads; and the removed operations are gone from the scope table, so the API's check that every operation has exactly one scope is strict again. What stored data needs in order to parse (old run and credential kinds, an agent team lead, retired rules and webhook events, old guardrail and integration settings) still parses, and a run's token is still PrincipalKind::Agent, which now means a run's token and the @g1t rows written before. The customize, marketplace, skills and claude-plugin contracts stay only until the mobile app drops its Customize screens.3d ago

oauth.rsArtifacts contracts: folios, their four kinds, dashboard datasets, folio events and the artifacts scopes are typed and validated the same in TypeScript and Rust, with nothing using them yet6d ago

oidc.rsMerge the OIDC docs: deploying to AWS, Google Cloud or Azure with a job's short-lived identity token now says which of the cloud's hosts to allow under Workflow-only domains, for the deploying workflow and environment, since a job on g1t's machines reaches only the hosts its project allows; and tests for the audience a job asks for and for the token variables reaching each step.3d ago

onboarding.rsMerge branch 'worktree-agent-ac7d6e0b40efe9fe8' into ship-batchyesterday

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

operations.rsAn issue says what closed it, linked: on flagon-io/demo #1 the session that built the page closed the issue through the issue tool's close, and its timeline said only "syntaqx closed this as completed", with nothing to follow to the commit that did the work or the session that made it. close_issue (REST, the MCP issue tool's close, `g1t issue close --commit`) now takes an optional commit: one on the default branch (repos' log and branch_drift) whose message names the issue after a closing keyword (closing::references). The issue then closes as completed in that commit exactly as its push would (close_by_commit: resolved_commit, "closed this in <commit>", issue.closed with commit), by the caller; a commit not on the default branch, or one not naming the issue, is refused saying why, and an already-closed issue says what closed it. The work service's CloseIssueArgs flattens IssueActionArgs, so integrations and security keep calling close_issue as they do. When an issue is closed in a session, the note ends "via session ses_…" and issue.closed carries session: the session the closing commit names in a G1t-Session trailer (on a push too), or, for a close made with a token, the closer's own active session on the issue (attached or linked; the person it acts for when it acts for one). The timeline renders that id as a session chip linking /<owner>/<repo>/work/sessions/<id>, next to the existing commit chip and #N links (messageParts gains a session part). The pull requests guide's Closing issues, the sessions guide, webhooks, the API reference notes, openapi.json, the CLI reference and ops table say so. Deploy: work and api together, then the site; the CLI flag ships with the next CLI release. Checked: cargo test -p g1t-work (202), -p g1t-api (209, openapi regenerated), -p g1t-contracts, -p g1t (ops_table and cli_reference regenerated); wasm32 check of g1t-work and g1t-api; apps/web npm run typecheck; node --test app/lib/commit-message.test.ts.yesterday

packages.rsMerge packages: roles, Actions access, source label, soft delete, API1w ago

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

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

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

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

reference.jsonAn issue says what closed it, linked: on flagon-io/demo #1 the session that built the page closed the issue through the issue tool's close, and its timeline said only "syntaqx closed this as completed", with nothing to follow to the commit that did the work or the session that made it. close_issue (REST, the MCP issue tool's close, `g1t issue close --commit`) now takes an optional commit: one on the default branch (repos' log and branch_drift) whose message names the issue after a closing keyword (closing::references). The issue then closes as completed in that commit exactly as its push would (close_by_commit: resolved_commit, "closed this in <commit>", issue.closed with commit), by the caller; a commit not on the default branch, or one not naming the issue, is refused saying why, and an already-closed issue says what closed it. The work service's CloseIssueArgs flattens IssueActionArgs, so integrations and security keep calling close_issue as they do. When an issue is closed in a session, the note ends "via session ses_…" and issue.closed carries session: the session the closing commit names in a G1t-Session trailer (on a push too), or, for a close made with a token, the closer's own active session on the issue (attached or linked; the person it acts for when it acts for one). The timeline renders that id as a session chip linking /<owner>/<repo>/work/sessions/<id>, next to the existing commit chip and #N links (messageParts gains a session part). The pull requests guide's Closing issues, the sessions guide, webhooks, the API reference notes, openapi.json, the CLI reference and ops table say so. Deploy: work and api together, then the site; the CLI flag ships with the next CLI release. Checked: cargo test -p g1t-work (202), -p g1t-api (209, openapi regenerated), -p g1t-contracts, -p g1t (ops_table and cli_reference regenerated); wasm32 check of g1t-work and g1t-api; apps/web npm run typecheck; node --test app/lib/commit-message.test.ts.yesterday

renamed.rsMerge branch 'worktree-agent-a8385d293d42c913a'1w ago

responses.rsMerge branch 'worktree-agent-ac7d6e0b40efe9fe8' into ship-batchyesterday

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

rules.rsThe contracts no longer describe g1t's own agents, and workspaces can keep their AI providers. Every consumer had already stopped using them, so the TypeScript and Rust contracts drop the workspace-agent, ability, look, skill-library, context, runner-agent and mention modules, the chat and docs RPCs agents posted and read through, the folio agent methods, the agent_waiting notification, agent.asked and memory.changed events, AI credit, token and gateway billing types, model routes and sessions, team agents, agent tokens, plan, review, message and confidence types, command rules, cost caps and confidence rules. The agents:run and models:* scopes are no longer offered by any preset, OAuth default or permission form, but a stored token or grant that names them still reads; and the removed operations are gone from the scope table, so the API's check that every operation has exactly one scope is strict again. What stored data needs in order to parse (old run and credential kinds, an agent team lead, retired rules and webhook events, old guardrail and integration settings) still parses, and a run's token is still PrincipalKind::Agent, which now means a run's token and the @g1t rows written before. The customize, marketplace, skills and claude-plugin contracts stay only until the mobile app drops its Customize screens.3d ago

run_artifacts.rsThe artifacts service is services/artifacts, the Worker g1t-artifacts, bound as ARTIFACTS by the API, the site and the agents; its live rooms move to it with a Durable Object transfer from g1t-docs-service, and its database, bucket, indexes and queue keep their names. The git store's binding and settings are GITSTORE, its ops scripts gitstore-*, and workflow run artifacts keep their compatible API under run_artifacts modules. The deploy tool puts a Worker that has never deployed before the Workers in its stage that bind to it, and the deploy guide gives the cutover runbook.6d ago

runners.rsA computer whose runner is registered again takes its own runner's name back instead of being refused. When the desktop app's sandbox was made again (a new VM, its registration gone), its runners registered under the names the old sandbox's still held on g1t, were refused with a 409 asking for --replace, and tried again forever. A runner now says which computer it is when it registers: a fingerprint g1t-runner works out from the operating system's machine id (Windows' MachineGuid, macOS's platform UUID, Linux's /etc/machine-id), hashed so the id never leaves the computer, or from --machine / G1T_RUNNER_MACHINE; a container sends none, since its machine id is its image's, and g1t-runner sandbox passes the computer's to the runner in the VM. The actions service keeps it hashed again with the workspace (migration 0022 adds runners.machine_hash), and a registration of a name already taken replaces that runner when it was registered from the same computer, or, for a runner from before fingerprints, when the same person made both tokens and the old runner has been offline for 90 seconds; a runner of the same name from another computer is still refused without --replace, and the refusal says so. The self-hosted runners guide covers registering again and --machine.3d ago

security.rsMerge commit '9232a85b'yesterday

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

token_policy.rsOne kind of access token; presence and status; usernames keep their case; the tour is a miniature of the real app; icons for password managers1w ago

toolkit.rsThe artifacts service is services/artifacts, the Worker g1t-artifacts, bound as ARTIFACTS by the API, the site and the agents; its live rooms move to it with a Durable Object transfer from g1t-docs-service, and its database, bucket, indexes and queue keep their names. The git store's binding and settings are GITSTORE, its ops scripts gitstore-*, and workflow run artifacts keep their compatible API under run_artifacts modules. The deploy tool puts a Worker that has never deployed before the Workers in its stage that bind to it, and the deploy guide gives the cutover runbook.6d ago

tools.rsAn issue says what closed it, linked: on flagon-io/demo #1 the session that built the page closed the issue through the issue tool's close, and its timeline said only "syntaqx closed this as completed", with nothing to follow to the commit that did the work or the session that made it. close_issue (REST, the MCP issue tool's close, `g1t issue close --commit`) now takes an optional commit: one on the default branch (repos' log and branch_drift) whose message names the issue after a closing keyword (closing::references). The issue then closes as completed in that commit exactly as its push would (close_by_commit: resolved_commit, "closed this in <commit>", issue.closed with commit), by the caller; a commit not on the default branch, or one not naming the issue, is refused saying why, and an already-closed issue says what closed it. The work service's CloseIssueArgs flattens IssueActionArgs, so integrations and security keep calling close_issue as they do. When an issue is closed in a session, the note ends "via session ses_…" and issue.closed carries session: the session the closing commit names in a G1t-Session trailer (on a push too), or, for a close made with a token, the closer's own active session on the issue (attached or linked; the person it acts for when it acts for one). The timeline renders that id as a session chip linking /<owner>/<repo>/work/sessions/<id>, next to the existing commit chip and #N links (messageParts gains a session part). The pull requests guide's Closing issues, the sessions guide, webhooks, the API reference notes, openapi.json, the CLI reference and ops table say so. Deploy: work and api together, then the site; the CLI flag ships with the next CLI release. Checked: cargo test -p g1t-work (202), -p g1t-api (209, openapi regenerated), -p g1t-contracts, -p g1t (ops_table and cli_reference regenerated); wasm32 check of g1t-work and g1t-api; apps/web npm run typecheck; node --test app/lib/commit-message.test.ts.yesterday

why.rs`why` no longer hands out commit authors' email addresses. Why a line is the way it is (API why, MCP repository why) returned the blamed commit as git stores it, author address included, to anyone who can read the repository. Its commit is now a WhyCommit: the author is named as git wrote them and by `username`, the g1t account their address belongs to (a confirmed or noreply address, or g1t's own), as list_commits already does, and the address is never returned. The guide, the operation's description, its example and the OpenAPI document say so. Checked: cargo test for g1t-contracts (new: an author is named by account, never by address) and g1t-api (204, the OpenAPI document regenerated), the CLI's (149), cargo check --workspace and g1t-api's wasm32 build.yesterday