@markjaquith/agency 2.47.3 → 2.48.1

package/skills/agency/references/contracts.md

@@ -1,322 +0,0 @@
-# Agency Data Contracts
-
-Use Agency JSON output instead of scraping human tables. Entity IDs are directory
-names; they are not duplicated in frontmatter.
-
-## Context Contract
-
-`agency context . --json` returns a versioned success envelope whose result
-contains:
-
-- `projection`: `compact` for root discovery by default, otherwise `complete`
-  unless compact entity context was explicitly requested;
-- `workbase`: root, config path, and config version;
-- `target`: resolved workbase, epic, task, or phase identity;
-- `discovery`: at the workbase root, all valid epic, task, and phase documents;
-- `documents`: ancestor frontmatter, paths, SHA-256 revisions, and prose;
-- `graph`: parent, dependencies, dependents, readiness blockers, and progress;
-- `authority`: `orchestration` or `execution`, one writable checkout or none,
-  and read-only references;
-- `workspace`: code path, materialization and registration state, commits, and
-  inspection warnings;
-- `pr`: recorded provider-neutral pull request identity and state; and
-- `validation`: validity and issues.
-
-Compact context retains identity, revisions, authority, paths, graph state,
-materialization, and warnings while omitting prose and low-level Git details.
-
-## Repository Declarations
-
-Tracked `agency.json` may contain portable repository declarations:
-
-```json
-{
-	"version": 2,
-	"repositories": {
-		"frontend": { "remote": "git@example.com:team/frontend.git" }
-	}
-}
-```
-
-Remotes are provider-neutral network Git remotes. Local paths, file URLs, and
-credential-bearing HTTP URLs are invalid. `repos/`, task and phase `code/`, and
-symlink targets are local-only and never part of this contract.
-
-Repository inspection returns `declaredRemote`, the actual local `remote`, and
-orthogonal `states`: `declared`, `materialized`, `linked`, `missing`, `invalid`,
-and `remote-drifted`. Setup JSON contains `mode`, `actions`, `unresolved`, and the
-post-operation `repositories`. Actions are `materialize` or `adopt`, with
-`planned` or `applied` status. Dry-run never mutates. Apply never overwrites a
-link or path and never repairs drift without an explicit remote choice.
-
-## Frontmatter Shapes
-
-### Epic
-
-```yaml
----
-ticketUrl: https://example.com/tickets/checkout
-description: Coordinate checkout delivery.
-repos:
-  - repo: frontend
-    ref: main
-tasks:
-  - id: api
-  - id: ui
-    dependsOn:
-      - api
----
-```
-
-Epics have read-only `repos`, never a writable `repo`. Their `tasks` list owns
-task ordering and task dependencies.
-
-### Single-Phase Task
-
-```yaml
----
-ticketUrl: null
-description: Refresh checkout copy.
-epic: checkout
-repo: frontend
-repos:
-  - repo: backend
-    ref: main
-branch: task/refresh-copy
-base: main
-pr: null
-status: open
----
-```
-
-### Multi-Phase Task
-
-```yaml
----
-ticketUrl: null
-description: Deliver checkout.
-epic: checkout
-phases:
-  - id: api
-  - id: ui
-    dependsOn:
-      - api
----
-```
-
-The task's `phases` list owns phase ordering and dependencies. Execution fields
-belong in each phase document.
-
-### Phase
-
-```yaml
----
-description: Build the checkout UI.
-repo: frontend
-repos:
-  - repo: backend
-    ref: main
-branch: task/checkout-ui
-base: task/checkout-api
-pr: null
-status: open
----
-```
-
-`ticketUrl` belongs to tasks and epics, not phases. `description` is optional but
-must be non-empty when present. `pr` is `null`, a legacy GitHub PR URL, or a
-provider-neutral record containing `provider`, `repository`, `identifier`, `url`,
-`state`, `draft`, `merged`, and optional `mergeable`. Mergeability is `true`,
-`false`, or `null` when the provider cannot determine it. New PR creation writes
-the structured record.
-Status is `open`, `working`, `delegated`, `done`, or `dropped`; `delegated` is
-readable legacy state but cannot be newly assigned.
-
-## Structural Invariants
-
-- An execution unit has one writable `repo`; plural `repos` are read-only
-  `{ repo, ref }` entries and cannot repeat the writable alias.
-- A writable `(repo, branch)` pair belongs to exactly one active execution unit.
-- `done` represents an authoritative merged pull request and is reconciled by
-  `agency sync --apply`; committed or review-ready work remains `working`.
-- Only `done` satisfies dependencies. `dropped` is terminal but blocks dependents.
-- Epic task dependencies live in `EPIC.md`; phase dependencies live in `TASK.md`.
-- IDs remain stable; use `dependsOn`, not numeric directory prefixes, for order.
-- YAML duplicate keys, anchors, aliases, and custom tags are invalid.
-- Use a commit SHA as a reference `ref` when reproducibility is required.
-
-## Graph Contract
-
-`agency graph --json` emits graph contract version 1. Stable node IDs are
-`epic:<id>`, `task:<id>`, `phase:<task>/<phase>`,
-`repository:<alias>`, and `execution-unit:<kind>/<id>`. Edge types are `owns`,
-`depends_on`, `writes`, and `references`.
-
-Every work node includes status, readiness, `blockedBy`, detailed blockers,
-terminal state, reverse dependents, and aggregate progress. Filters run after
-state computation. `--jsonl` emits a versioned `meta` record, node and edge
-records, then an `end` record; together they reconstruct the JSON result.
-
-## Machine Envelope
-
-The published success fixture is normalized from
-`agency init /work/agency --json`:
-
-```json
-{
-	"version": 1,
-	"ok": true,
-	"result": {
-		"root": "/work/agency"
-	}
-}
-```
-
-The published error fixture is the output of `agency unknown --json`:
-
-```json
-{
-	"version": 1,
-	"ok": false,
-	"error": {
-		"code": "CLI_USAGE",
-		"message": "Unknown command 'unknown'.\n\nUsage: agency <command> [options]",
-		"fields": {
-			"detail": "Unknown command 'unknown'.",
-			"usage": "agency <command> [options]"
-		},
-		"retryable": false,
-		"remediation": "Correct the arguments using the usage value in error.fields."
-	}
-}
-```
-
-These examples are exported from `fixtures/protocol/` and tested against real
-CLI subprocess output. The Effect schemas are exported by the package and by
-`@markjaquith/agency/protocol`. The distributable JSON Schemas are exported as
-`@markjaquith/agency/schemas/agency-envelope-v1.json` and
-`@markjaquith/agency/schemas/agency-graph-v1.json`.
-
-Only the envelope and graph result have published JSON Schemas. The envelope's
-`result` is intentionally unconstrained. Context, next, claim, prepare, sync,
-repository setup, and PR result shapes are exercised by CLI tests but do not have independent
-published schemas.
-
-### Output And Exit Guarantees
-
-- `--json` writes exactly one newline-terminated envelope to stdout on success
-  or failure. It disables interactive selection and takes precedence over
-  `--silent`; explicit entity selectors remain valid.
-- Human output is not a machine contract. Do not parse tables, progress text, or
-  diagnostic wording.
-- Progress and verbose diagnostics use stderr. Structured command warnings stay
-  inside the stdout result. Successful JSON mode does not promise empty stderr
-  when `--verbose` is requested.
-- Success, help, and version output exit `0`. Usage errors and every command
-  failure exit `1`. Version 1 has no error-specific exit statuses; branch on
-  `error.code`.
-- `graph --jsonl` is the one streaming exception. On success it writes a `meta`
-  record, node and edge records, and an `end` record rather than an envelope. A
-  JSONL failure still writes one error envelope and exits `1`.
-- A command that emits zero machine results succeeds with `result: null`.
-  Multiple results are a `PROTOCOL_OUTPUT_ERROR`.
-
-### Error Codes
-
-| Code                      | Meaning                                                        |
-| ------------------------- | -------------------------------------------------------------- |
-| `CLI_USAGE`               | Invalid command, option, argument, or combination              |
-| `WORKBASE_NOT_FOUND`      | No workbase could be resolved                                  |
-| `WORKBASE_CONFIG_INVALID` | Invalid workbase configuration                                 |
-| `WORKBASE_REGISTRY_ERROR` | Invalid or inaccessible workbase registry                      |
-| `FILE_NOT_FOUND`          | A required path does not exist                                 |
-| `FILESYSTEM_ERROR`        | A filesystem operation failed                                  |
-| `FRONTMATTER_INVALID`     | Durable document frontmatter is invalid                        |
-| `VALIDATION_FAILED`       | Workbase validation reported issues                            |
-| `REPOSITORY_ERROR`        | Repository operation failed                                    |
-| `EPIC_ERROR`              | Epic operation failed                                          |
-| `TASK_ERROR`              | Task operation failed                                          |
-| `PHASE_ERROR`             | Phase operation failed                                         |
-| `CLAIM_ERROR`             | Claim input or lifecycle state is invalid                      |
-| `CLAIM_CONFLICT`          | Active or legacy ownership conflicts with an operation         |
-| `REVISION_CONFLICT`       | A durable document changed since inspection                    |
-| `CLAIM_OWNERSHIP`         | The session does not own the active claim                      |
-| `ARCHIVE_ERROR`           | Archive or restore operation failed                            |
-| `WORKTREE_ERROR`          | Worktree operation failed                                      |
-| `PULL_REQUEST_ERROR`      | Pull request operation failed                                  |
-| `CONTEXT_ERROR`           | A context target or required document is invalid               |
-| `GRAPH_ERROR`             | Graph construction or filtering failed                         |
-| `EXECUTION_BLOCKED`       | Readiness or lifecycle blockers prevent execution              |
-| `SYNC_ERROR`              | Reconciliation validation, inspection, or provider data failed |
-| `PROCESS_ERROR`           | A child process failed                                         |
-| `PROTOCOL_OUTPUT_ERROR`   | A command violated the one-result machine contract             |
-| `COMMAND_FAILED`          | An otherwise unclassified failure                              |
-
-`CLAIM_CONFLICT`, `REVISION_CONFLICT`, and `PROCESS_ERROR` are retryable in the
-v1 metadata. Retryable means new evidence may change the result, not that blind
-or non-idempotent retries are safe. Inspect `fields` and apply `remediation`
-before retrying.
-
-## Revisions And Concurrency
-
-A document revision is the lowercase SHA-256 hash of the complete Markdown file,
-including frontmatter and prose. It is per document, not a workbase-wide graph
-revision. Context, graph, and entity reads expose revisions.
-
-`claim`, `release`, and `finish` require `--revision <sha256>`. They lock and
-recheck the execution document before an atomic replacement, then return
-`previousRevision` and the new `revision`. Use the returned revision or inspect
-again before the next mutation. Claim conflicts include the current revision and
-ownership evidence in `error.fields`; revision conflicts include ownership only
-when claim evidence applies.
-
-Structural update, rename, move, and dependency commands accept optional
-`--if-revision <sha256>`. Machine orchestrators should provide it. Multi-document
-mutations recheck every affected file while holding the graph mutation lock.
-
-## Selectors And Projections
-
-`--workbase <id|name|path>` selects a registered workbase by ID, name, or path;
-an existing path may also resolve an unregistered workbase directly. `--cwd
-<path>` asks Agency to perform target inference as if invoked there. They are
-mutually exclusive. Targeted commands accept `--epic`, `--task`, and `--phase`
-where applicable; phase requires task, and entity selectors cannot be combined
-with a positional target ID. Non-target positional values, such as a status
-outcome, remain valid where the command syntax requires them.
-
-`--json`, `--no-input`, and non-TTY execution disable interactive prompts and
-selection. Supply every required value or explicit entity selector. Global
-`--cwd` and `--workbase` selectors apply to `next` as they do to other discovery
-commands.
-
-At a workbase root, context defaults to a compact discovery catalog of epics,
-tasks, and phases, includes no writable authority, and provides a hint for
-requesting `--full`. Entity context defaults to the `complete` projection.
-`--compact` omits prose and low-level Git details but retains identity, document
-hashes, authority, paths, graph state, materialization, and validation warnings.
-
-Graph projections are opt-in with repeatable
-`--include <bodies|workspace|git|pr>`. Filters such as `--ready`, `--blocked`,
-`--status`, `--repository`, and `--kind` are applied after readiness and graph
-state are computed; returned edges always have both endpoints in the filtered
-node set.
-
-## Capability Boundaries
-
-- There is no atomic find-ready-and-claim operation. `next` is observational,
-  and `claim` does not enforce dependency readiness. Inspect readiness, then
-  claim with the observed revision and handle conflicts.
-- There is no `assign` command, remote queue, scheduler, heartbeat, claim renewal,
-  runner monitor, or cancellation API. `work` launches one local built-in or
-  configured runner without a claim; it is a process-launching, non-JSON flow
-  rather than a machine assignment API. External orchestrators claim with
-  claimant and runner IDs, then manage their runner themselves.
-- Agency does not edit code, create commits, run repository checks, wait for PR
-  checks, merge PRs, or verify that a requested completion condition is true.
-  `finish` records the caller's asserted outcome after ownership checks.
-- Reconciliation never discards changes, switches branches, resets reference
-  commits, moves conflicting worktrees, chooses among multiple PRs, or bypasses
-  active claims. Such conditions remain unresolved for a human or orchestrator.
-- `delegated` is readable legacy state but cannot be newly assigned. `--force`
-  only overrides readiness for `work` and `pr create`; it is not general
-  reconciliation authority.

package/skills/agency/references/recipes.md

@@ -1,264 +0,0 @@
-# Agency Recipes
-
-For an entity target, run `agency context . --json` before selecting a recipe.
-At the workbase root, use `agency next --json` or `agency graph --json` to choose
-a target, then inspect it with explicit `--epic`, `--task`, and `--phase`
-selectors or its returned document path. Graph node keys such as `task/<id>` and
-`phase/<task>/<phase>` are not positional context targets.
-
-The machine-orchestration forms in the inspect-through-recover recipes are
-captured in `fixtures/protocol/orchestration-recipes.json` and tested against the
-real CLI parser. Their lifecycle behavior is covered by CLI and service fixtures.
-Replace angle-bracket placeholders with values from context or a prior machine
-result; never scrape them from human output.
-
-## Initialize A Workbase
-
-For an existing local checkout, initialize the workbase and link the repository:
-
-```bash
-agency init <workbase-path>
-agency --workbase <workbase-path> repo link <alias> <repository-path>
-agency validate <workbase-path>
-agency --workbase <workbase-path> repo verify <alias>
-```
-
-Use `repo add <alias> <remote>` instead when Agency should create and manage a
-bare clone from a remote. Initialization and repository registration require
-explicit user intent.
-
-## Restore A Workbase On A New Machine
-
-After cloning the tracked workbase, inspect repository setup before applying it:
-
-```bash
-agency repo setup --dry-run --json
-agency repo setup --apply --json
-agency validate
-agency doctor --json
-```
-
-Apply clones only declared missing repositories. It does not overwrite linked
-checkouts, repair invalid paths, or choose between drifted remotes. Resolve those
-states explicitly, then rerun setup. A machine may replace an unused managed
-clone with `repo link`; the portable declaration remains available to every
-other machine.
-
-## Inspect A Target
-
-```bash
-agency context --task <task-id> --phase <phase-id> --json
-agency worktree inspect <task-id> <phase-id> --json
-```
-
-Confirm the target, current document revision, readiness, authority, checkout,
-claim, PR, and validation state. Use `--compact` only when prose and detailed Git
-evidence are not needed.
-
-## Find Ready Work
-
-Run this from the intended workbase:
-
-```bash
-agency next --json
-agency graph --ready --json
-```
-
-`next` ranks ready execution units and explains every excluded unit. It does not
-reserve work. Another orchestrator may claim the same candidate before you do,
-so always handle `CLAIM_CONFLICT` or `REVISION_CONFLICT`.
-
-## Human: Create And Launch Work
-
-```bash
-agency task create refresh-copy --repo frontend --branch task/refresh-copy --base main
-agency validate
-agency work tasks/refresh-copy
-```
-
-For a multi-PR outcome:
-
-```bash
-agency task create checkout --multi-phase
-agency phase create checkout api --repo backend --branch task/checkout-api --base main
-agency phase create checkout ui --repo frontend --branch task/checkout-ui \
-  --base main --reference backend:main --depends-on api
-agency validate
-agency work tasks/checkout/phases/api
-```
-
-`agency work` is intentionally last: it synchronizes managed integration files,
-checks readiness, materializes worktrees, marks this execution unit working
-without a claim, and launches the runner. Run it again to relaunch unclaimed
-working work. The runner opens without a prompt by default; add `--auto` only
-when the generated context prompt should start autonomous execution.
-OpenCode receives whole-workbase visibility through the managed project plugin;
-this does not expand the writable checkout reported by `agency context`.
-
-## Active Agent: Execute Assigned Work
-
-```bash
-agency context . --json
-```
-
-1. Verify context reports the expected execution target, valid structure, and
-   the current checkout as `authority.writable.checkoutPath`. Reject dependency
-   or validation blockers and conflicting active claims.
-2. Read `TASK.md`, and `PHASE.md` for phase work.
-3. Implement only in the writable checkout; treat all reference checkouts as
-   read-only.
-4. Run repository formatting, checks, build, and focused tests.
-5. Review and commit the diff.
-6. If requested, run `agency validate`, then
-   `agency pr create <task-id> [phase-id]`.
-7. Finish an active claim after its completion condition is true; otherwise set
-   the task or phase status directly.
-
-Never invoke `agency work` merely because an execution checkout already exists;
-that would start another agent rather than continue the current assignment.
-
-## Claim Ready Work
-
-Get the current document revision from context. Use stable claimant, runner, and
-session IDs:
-
-```bash
-agency claim checkout ui \
-  --claimant orchestrator-1 --runner opencode --session-id session-123 \
-  --revision <sha256> --json
-```
-
-Claim records ownership and sets status to `working`; it does not launch a runner
-or recheck dependency readiness. A machine orchestrator must launch and monitor
-its runner separately. There is no atomic find-and-claim or `assign` command.
-
-## Prepare Checkouts
-
-Preview and then materialize without claiming, launching, or changing status:
-
-```bash
-agency work prepare --task checkout --phase ui --dry-run --json
-agency work prepare --task checkout --phase ui --json
-```
-
-Use the returned checkout paths and resolved commits. Do not create or move
-worktrees manually.
-
-## Assign A Runner
-
-For a human-operated local launch, Agency combines readiness checks, prepare,
-status mutation, and runner launch without creating a claim:
-
-```bash
-agency work tasks/checkout/phases/ui --runner opencode
-```
-
-This is not a JSON assignment API. An external orchestrator instead claims with
-its own `claimant`, `runner`, and `session-id`, starts the runner outside Agency,
-and passes it the target and claim result. Agency has no queue, heartbeat,
-monitoring, cancellation, or automatic claim-renewal service.
-
-## Reconcile Durable And Local State
-
-```bash
-agency sync --dry-run --json
-agency sync --apply --json
-```
-
-The first command is observational. Apply may materialize an unconflicted missing
-checkout, release an expired claim, record one unambiguous matching PR, or mark
-unclaimed work done after its authoritative PR merges. Review `warnings` and
-`unresolved`; apply never discards or resets work and never chooses among
-ambiguous PRs.
-
-## Release Interrupted Work
-
-After every claim mutation, use the returned revision or inspect again. Release
-interrupted work back to open:
-
-```bash
-agency release checkout ui --session-id session-123 \
-  --revision <current-sha256> --json
-```
-
-## Finish Verified Work
-
-After the claimed run completes successfully:
-
-```bash
-agency finish checkout ui --session-id session-123 \
-  --revision <current-sha256> --outcome done --json
-```
-
-Do not substitute a phase status mutation for `finish`; `finish` preserves
-ownership history and revision safety. A `done` claim outcome leaves unmerged
-execution work `working`. After the authoritative pull request merges, use
-`agency sync --apply` to reconcile the execution unit to `done`.
-
-## Create A Pull Request
-
-```bash
-agency validate
-agency pr create checkout ui --json
-```
-
-Agency materializes a missing workspace, then requires the writable worktree to
-be clean. It pushes the declared branch, invokes the configured delivery
-provider's create command or falls back to `gh pr create --fill`, and records the
-returned pull request record. Do not manually write a URL or record if creation
-fails. A PR being open is not equivalent to completion when the assigned outcome
-requires merge.
-
-Agency does not create commits, run tests, wait for checks, merge the PR, or
-verify completion. Those remain orchestrator responsibilities.
-
-## Convert A Task To Phases
-
-Name the phase that inherits the existing task's execution metadata:
-
-```bash
-agency phase create refresh-copy verification \
-  --first-phase implementation \
-  --repo frontend --branch task/refresh-copy-verification --base main \
-  --depends-on implementation
-agency validate
-```
-
-Agency converts the task shape, creates both phase documents, and relocates
-materialized worktrees. Do not perform those moves manually.
-
-## Recover From Interrupted State
-
-Inspect before applying changes:
-
-```bash
-agency doctor --json
-agency sync --dry-run --json
-agency worktree inspect <task-id> [phase-id] --json
-agency worktree repair <task-id> [phase-id] --dry-run --json
-```
-
-Use `agency sync --apply` only with explicit user intent. It may safely
-materialize an unconflicted missing checkout, release an expired claim, record a
-single matching PR, refresh recorded PR state and mergeability, or mark work done
-after its authoritative PR merged and no claim remains. It never modifies dirty
-checkouts, switches branches, resets
-references, chooses among PRs, or bypasses active claims.
-
-For a worktree-specific issue, use `worktree repair --dry-run` before repair.
-Repair is conservative and never discards work. Use remove or rebuild only after
-reviewing the dry run and confirming every checkout is clean.
-
-## Archive Or Restore
-
-```bash
-agency archive phase checkout ui --dry-run --json
-agency archive phase checkout ui
-agency restore phase checkout ui --dry-run --json
-agency restore phase checkout ui
-```
-
-As an operating policy, archive only terminal work and only with explicit intent;
-the CLI also permits safe archival of nonterminal work. Agency preserves the
-branch and lifecycle provenance while enforcing graph, worktree, and destination
-safety. Never move archived directories by hand.

package/src/workbase/AGENCY_COMMAND.md

@@ -1,48 +0,0 @@
----
-description: Operate Agency work with safe start, status, next, validate, and finish workflows
----
-
-Operate the current Agency workbase using the managed Agency instructions.
-
-Invocation inputs:
-
-- Workflow: `$1`
-- Optional target: `$2`
-- Complete request: `$ARGUMENTS`
-
-Use `status` when the workflow is empty. Treat words after the optional target as
-additional user instructions. If the workflow is unknown, make no changes and
-list the supported workflows.
-
-Always follow these rules:
-
-- Run `agency context . --json` first when no target is provided. With a target,
-  pass that target to `agency context` instead.
-- Use the returned document paths, readiness, authority, checkout state, claim,
-  and validation result. Do not infer them from directory names.
-- Stop on validation errors, dependency blockers, an unexpected writable
-  repository, or a conflicting active claim.
-- Write code only in `authority.writable.checkoutPath`; references are read-only.
-- Never run `agency work` to start the current agent again.
-- Create a pull request only when the complete request explicitly asks for one.
-
-Dispatch the workflow as follows:
-
-- `start`: Read the returned task and phase documents, inspect the writable
-  checkout, then begin or resume the requested work in this session. Keep durable
-  decisions current and carry the work through focused verification.
-- `status`: Make no changes. Summarize the target, readiness, authority, durable
-  status, claim and PR state, checkout state, current Git changes, blockers, and
-  the most useful next action.
-- `next`: Run `agency next --json`, summarize ready and blocked execution units,
-  and recommend the highest-priority ready unit. Do not launch another agent.
-- `validate`: Run Agency validation for the discovered workbase. Explain every
-  issue and, when safe and within authority, repair requested non-structural
-  problems before validating again.
-- `finish`: Complete any remaining requested implementation first. Run focused
-  repository checks, refresh the task or phase delivery context, and run
-  `agency validate`. Finish an active claim with its current revision; otherwise
-  update unclaimed status only when the requested outcome and delivery work are
-  actually complete. Do not create a PR unless explicitly requested.
-- `help`: Make no changes. Briefly explain these workflows and the positional
-  form `/agency <workflow> [target] [additional instructions]`.

package/src/workbase/opencode-command-file.ts

@@ -1,30 +0,0 @@
-import { createHash } from "node:crypto"
-import commandTemplate from "./AGENCY_COMMAND.md" with { type: "text" }
-
-const managedHeaderPattern =
-	/^---\r?\n# agency-managed: sha256=([a-f0-9]{64})\r?\n/
-
-const checksum = (content: string) =>
-	createHash("sha256").update(content).digest("hex")
-
-const canonicalBody = commandTemplate.endsWith("\n")
-	? commandTemplate
-	: `${commandTemplate}\n`
-
-const renderManagedWorkbaseOpencodeCommand = (
-	content: string = canonicalBody,
-) =>
-	content.replace(
-		/^---\n/,
-		`---\n# agency-managed: sha256=${checksum(content)}\n`,
-	)
-
-export const managedWorkbaseOpencodeCommand =
-	renderManagedWorkbaseOpencodeCommand()
-
-export const canUpdateManagedWorkbaseOpencodeCommand = (content: string) => {
-	const match = content.match(managedHeaderPattern)
-	if (!match?.[1]) return false
-
-	return checksum(content.replace(managedHeaderPattern, "---\n")) === match[1]
-}