Status: adopted with revisions for opt-in, human-supervised StratoFusion work.
The Agent Delivery Harness is a repository workflow, not an autonomous agent
platform. It connects risk classification, isolated task branches, explicit
resource leases, deterministic verification, independent read-only review, and
a human merge handoff. It does not replace AGENTS.md, the feature workflow,
CI, CASA, security scanners, or human approval.
Adoption boundary
The five-trial evidence-backed delivery pilot is complete. The sole maintainer
chose adopt with revisions on 3 September 2026. v1 remains opt-in because
the trial measured one maintainer's workflow, not an independent review team:
five suitable pull requests completed the pilot;
four usefulness responses were recorded: three yes and one partly;
every response was sole-maintainer self-review;
four timed trials totalled 13 minutes of pilot-specific maintenance;
there were zero confirmed privacy incidents;
the trial established no 10x, throughput, review-time, or time-savings claim.
The original reports remain the historical record. Do not open more pilot rows
or describe v1 work as another trial.
Prerequisite blocker
Unattended writing agents are disabled until enforced branch protection is
available on both private dev and main. A read-only GitHub API check on 3
September 2026 returned 403 for both branches and said the repository must be
upgraded to GitHub Pro or made public to enable branch protection. Neither
repository visibility, plan, nor settings may be changed by the harness.
Until a human resolves that prerequisite and separately approves a revised
operating mode, agents may prepare task branches and draft pull requests only
under active human supervision. They may not merge, approve, deploy, publish,
or write directly to either long-lived branch.
Human-confirmed risk tiers
A human confirms the tier before a writing lease begins. Automation may
recommend the same or a higher tier; it must never lower the confirmed tier.
Tier
Scope
Required control
T0
Read-only research or documentation work
No mutation outside the task worktree; cite sources and state evidence gaps.
T1
Routine isolated code, tests, or non-sensitive UI
Isolated worktree, focused checks, review, and human merge.
T2
Provider, auth, billing, database, rclone, CI, or deployment work
Human plan approval and exclusive resource assignment before implementation.
T3
Production/customer data, destructive transfers, migrations, or external communications
Explicit human approval for every action; never autonomous.
If scope expands, stop and obtain confirmation for the higher tier before
continuing. A lower-risk implementation cannot silently authorize a higher-risk
verification step.
repair is used only when review finds a material issue. A repaired change
returns to verifying and then reviewing. The maximum is two repair cycles.
If the same failure remains after the second repair cycle, stop with a blocked
handoff rather than looping.
Terminal states are completed, blocked, rejected, and abandoned.
completed: the task PR was human-merged to dev, or a non-writing task met
its explicitly approved outcome.
blocked: the task cannot safely progress and records the failed prerequisite.
rejected: a human declined the proposed change.
abandoned: work stopped without an adoption or correctness claim.
human-ready is not approval. It means the draft PR and evidence are ready for
the human decision.
Concurrency and isolation
At most two writing agents may be active at once. Read-only research or review
does not consume the writing limit, but it must not edit the worktree.
Each writing task uses a unique Windows-native Git worktree and branch from the
latest origin/dev. origin/main is reserved for an explicitly approved
release, hotfix, or maintenance workflow. Before editing, inspect dirty
worktrees, open pull requests, and overlapping files.
Worktrees isolate tracked files and branches. They do not isolate ports,
processes, PostgreSQL, OAuth accounts, provider state, billing data, rclone
workers, local VMs, CI capacity, or other shared services. Those resources must
be named and exclusively assigned where required.
Local lease contract
Writing tasks use a small JSON lease under the ignored
.tmp/agent-delivery/leases/ directory. A lease records:
task and owner;
human-confirmed risk tier and an explicit confirmation flag;
lifecycle state and repair-cycle count;
ports and shared services;
exclusive resources;
start and expiry timestamps;
held/released state and release timestamp.
Create a lease only after checking existing worktrees, pull requests,
processes, ports, and local lease files:
The helper rejects invalid, duplicate, expired, or over-broad fields and will
not overwrite an existing lease. It does not discover conflicts, reserve an
external resource, schedule work, or enforce the two-agent limit. The human and
agents remain responsible for the read-only conflict checks.
Independent review and repair
Review must be a separate pass with fresh task context and read-only access.
The reviewer:
reads the acceptance criteria, confirmed risk tier, relevant canonical
docs, and the complete diff;
reports evidence-backed findings by severity with file and line references;
distinguishes regressions from pre-existing failures and evidence gaps;
does not edit the implementation, approve its own work, or turn an AI score
into a correctness claim.
CI, CASA, GitGuardian and other configured scanners remain authoritative for
their gates. A separate implementation pass repairs accepted findings, reruns
the relevant checks, and returns the change to independent review. Two repair
cycles is the hard limit.
In a sole-developer repository, the same person may perform the final human
review, but it must be recorded as self-review. It is not independent evidence.
Evidence policy
Use deterministic tests and source inventories first. Runtime evidence is
optional and must answer a real review question.
pnpm evidence:pr defaults to a single current-state capture of
http://127.0.0.1:3000/. A before/after comparison is available only when both
inputs are explicit. The helper:
permits loopback HTTP(S), GET/HEAD, and inert browser resources only;
validates the final navigation URL and requires a 2xx response;
rejects embedded credentials and sensitive query-key names;
blocks remote subresources, unsafe methods, service workers, and downloads;
validates existing PNG size, signature, and dimensions, then re-encodes the
pixels through the existing Playwright dependency to strip metadata;
records base SHA, head SHA, clean/dirty state, and a SHA-256 diff digest, but
never writes the raw diff or changed paths;
labels --verification-note values as author-supplied metadata and never
executes them;
writes only to .tmp/pr-evidence/<task>/ and uploads nothing.
Do not use production, customer data, provider accounts, billing, OAuth,
admin, private filenames, credentials, browser storage, environment values, or
mutation-capable routes. Inspect every image before sharing it. Evidence is a
review aid, not proof of correctness, security, accessibility, or production
readiness.
Pull-request and release path
The only normal path is:
task PR -> dev -> human merge -> separate release PR -> main -> human release approval -> immutable-SHA deploy
An agent never pushes directly to main, merges either PR, approves its own
change, triggers a deployment, or treats human-ready as release approval.
Production deployment must retain the existing immutable-SHA CI gate.
The task PR must state exact checks and results, privacy review, rollback,
limitations, confirmed tier, lifecycle outcome, repair count, lease release,
and the branch-protection blocker. Article and social drafts remain unpublished
unless a separate human-authorized publishing task occurs.
Rollback
The harness is intentionally shallow. Revert the harness documentation,
templates, local lease scripts/tests, evidence-helper revisions, package script,
and ignore entry. Local lease/evidence directories can be removed after review
because they are ignored artifacts. Reverting v1 must not rewrite the completed
pilot reports.
Future discovery only
An “agent-safe cloud-storage control plane” is not part of v1. A separate
discovery task would need capability-scoped identities, provider/account/resource
leases, dry-run and plan artefacts, idempotency keys, policy evaluation,
approval receipts, immutable audit events, bounded execution, cancellation,
reconciliation, and customer-visible recovery semantics before any design or
implementation decision.