Skip to main content

​
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:
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.