> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sequency.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent delivery

# Agent delivery discipline

This is the vendor-neutral delivery policy for AI-assisted Sequency work. Agent
entrypoints may add repository-specific safety rules, but they must not weaken or
silently fork this policy.

## Outcome and work in progress

Work from one explicit product outcome and one active release packet at a time.
An epic may contain many important issues; only dependencies named in the active
packet can interrupt it. New evidence may promote a dependency, but the agent
must record why before changing scope.

For the #1740 recovery, the active outcome is a truthful, product-owned P2/P3
research result. The release train is:

1. **Release A — P3-C2:** immutable campaign input -> canonical worker -> durable
   ledger.
2. **Release B — P2:** primary-record portfolio metrics plus exact-window SPY and
   QQQ total-return comparisons -> authenticated product response.
3. **Release C — P3-C3:** exploration selection -> sealed holdout -> one
   production-ready evidence and authenticated product integration.
4. **Release D — AA-1:** a curated canonical REST/OpenAPI profile -> typed
   Python SDK -> remote MCP adapter, with cross-interface conformance.
5. **One-shot acceptance:** submit the frozen campaign exactly once through the
   authenticated product path -> terminal `edge_found`, `no_edge_found`, or
   `insufficient_evidence` decision. SDK/MCP acceptance adopts and reads that
   same campaign identity; it never creates a second outcome-bearing run.

Issues #746, #909, #2379, #2380, full external onboarding, and general engine
breadth remain deferred unless the active release produces evidence that one is
required for its exit gate. The bounded AA-1 SDK/MCP interface is part of the
release train; product-scale OAuth/PAT onboarding, tenancy, billing, retention,
and SLO work remain in #2325/#2326/#2327.

## Frozen campaign

“Frozen” describes the experiment, not the software. Before any outcome is
observed, the campaign fixes its hypotheses, ordered universe, score-set identity,
dates, exploration/holdout split, cost model, benchmark contract, controls, and
decision thresholds. Software defects may be fixed and the same immutable inputs
may be resumed idempotently. The campaign must not be tuned, widened, or rerun
under the same identity after outcomes are visible.

The governing contract is
`docs/superpowers/specs/2026-09-04-canonical-frozen-confluence-campaign.md`.

## Acceptance-first vertical delivery

Before implementation, write or identify the smallest end-to-end acceptance test
that crosses the release boundary. It should fail for the missing capability and
pass only when the product path is usable. If a local end-to-end test is impossible,
record the exact production acceptance probe before coding.

Build vertically through the real ownership seams. Do not complete every schema,
storage, worker, or UI concern as a horizontal tranche before exercising the
product path. Review the proposed seam at the start, once at the first meaningful
cross-boundary midpoint, and again on the exact final diff.

For Release B, freeze the authenticated P2 response contract as soon as its
consumer test is accepted. The App may build against that version while backend
work continues. Later incompatible changes require a new contract version; absent
financial data remains explicit and is never replaced by mock or neutral values.

## Token discipline

Token discipline is a context-management practice, not a fixed token quota and
not permission to stop before the active packet is complete.

Do not load an entire epic, historical plan, or long handoff into every working
context. The coordinating agent extracts only the active packet: outcome, exit
gate, exact seams, relevant invariants, allowlisted paths, checks, base/head, and
known blockers. Open broader material only when a concrete ambiguity requires it.

Use bounded delegation when parallel work will shorten the critical path:

* delegate mechanical or independent work such as fixtures, migrations, schema
  mirrors, echo sweeps, lint fixes, golden regeneration, and inventories;
* keep architecture decisions, identity/hash semantics, canonical serialization,
  campaign governance, security disposition, final review, and promotion in the
  coordinating loop;
* use one writer for any overlapping file set; parallel read-only reviews and
  independent seams are allowed;
* give each child a fresh one-use packet rather than parent conversation history;
* require returns to contain changed paths, concise decisions, commands with exit
  status, and remaining risk. Do not return file dumps, transcripts, or rewritten
  plans.

Compaction or handoff summaries must preserve only the active outcome, packet,
base/head SHA, worktree, changed paths, invariants, test evidence, delivery state,
and next blocking action.

Use the governed Sol/Luna skill when the runtime exposes it. A runtime without
that hook must still use the same bounded task and return shape and must state
that model/scope enforcement was behavioral rather than harness-enforced.

## Verification economy

During implementation, run the narrowest deterministic test that can disprove the
current change. Once the focused loop is green, broaden only when a new change,
failure, or unresolved risk justifies it. Do not repeatedly run an unchanged full
matrix. GitHub Actions owns the unchanged full lint, type, test, security, and
deployment matrices.

For the P2/P3 data path, use the checked-in command:

```bash theme={null}
scripts/verify-backtesting-release.sh fast
```

Run `scripts/verify-backtesting-release.sh release` once on the final candidate
before promotion. It adds the pinned API lint, migration lint, and race-enabled
kernel closure. CI remains authoritative.

## Evidence and status

Never collapse delivery states. Report each applicable state independently:

1. `implemented` — local diff exists and focused checks pass;
2. `reviewed` — exact diff and required security review are accepted;
3. `merged` — protected merge completed at an exact SHA;
4. `deployed` — CI deployed that SHA and the relevant process loaded it;
5. `product_accepted` — the product flow and primary records satisfy the packet
   exit gate.

Progress updates name the active release, current state, evidence gained since the
last update, the next blocking action, and any scope change. Time spent is not a
substitute for this evidence.

## Reduced delivery bar (operator ruling, 2026-09-11)

The per-strategy acceptance ceremony and the four-tranche PR pipeline were the main cause of
the July–August slowdown. From 2026-09-11, for every agent working in this workspace:

1. Platform-level proofs — restart durability, negative promotion (P9), the three-transport
   REST/SDK/MCP reread, loaded-process cohort proofs — were established once on the Original and
   Modified profiles. Never repeat them per strategy. A strategy is accepted when it runs on
   production data through the ordinary authenticated path and its judged result is readable
   (run id and result hash linked from the issue).
2. One PR per remaining profile, one review round (correctness and security in a single pass).
   The receipt and `security-review-gate` status remain only because the org ruleset requires them.
3. No spec or plan documents for internal work: a one-page decision note, then code, then a short
   "what shipped" section. No evidence bundles committed to git; artifacts live in the databases
   and are linked by hash or run id.
4. Process freeze: no new gate, rule, census entry or convention without deleting one.
5. Status reports are short and plain: implemented / merged / deployed / accepted, nothing else.