Mission order — agentic-system analysis operability hardening

This plan uses the transferable mechanism behind Auftragstaktik: fix the intent, binding bounds, acceptance evidence, authority, and return conditions; leave execution-time choice of means to the executor. The governing Commonplace accounts are intent-framed delegation and the rule to fix what the executor cannot determine.

Situation

The first post-promotion analysis completed and produced a sound bounded result, but its failure diagnostic records source-acquisition friction, unsafe inspection ergonomics, an in-flight register correction, ambiguous validation output, late output routing, loss of the local canonical result, and shared-worktree interference. The exact result was later recovered into cache, but cache is disposable and therefore cannot become its authoritative carrier.

Several governing rules already exist in the analysis skill. The failure is therefore not one missing instruction. The workflow relies on the executor to remember phase, authority, validation, and retention state across a large analysis. Separately, the reviewed repository contradicts itself about its persistent-FAIL transition; that is source evidence, not a Commonplace runtime failure.

Intent

Purpose

Make an agentic-system analysis recoverable and operationally trustworthy without turning one workflow's bookkeeping into a premature general framework.

Desired end state

Before execution, every run declares its source boundary, canonical-result carrier, permitted projections, and write authority. During execution, source freezing, runtime-baseline sealing, lens packets, corrections, validation, and handoff have inspectable identities and enforced ordering. At handoff, the declared canonical result still exists in its lifecycle-valid carrier, its validation proves the intended typed subject was inspected, and any compact collection analysis remains an explicitly derived projection.

The normal Commonplace operator route must not leave the only exact result in a transient chat or disposable cache. A deliberately response-only run remains possible only when that disposition was explicit before execution and no local consumer requires the exact result.

Required effects

  • Settle result lifecycle. Identify the consumers of the exact result and choose one canonical carrier and retention rule that distinguish response, operational state, retained report, and compact library projection.
  • Make phase state enforceable. Prevent lens dispatch before the runtime baseline is sealed; version every supplied register and correction; and join validation and handoff to the exact assembled artifact.
  • Harden source inspection. Reach one immutable source without needless credential retries, anchor every command to the frozen source root, and never use truncated output as evidence.
  • Make validation decisive. Establish the expected file count and type from machine-readable output. Change validator terminology or behavior only after exact failure evidence identifies the defect.
  • Retain useful failure evidence. Record enough command, environment, phase, output, and producer identity to distinguish a tool failure, execution error, expected invalidation, environmental condition, and source conflict.
  • Prove the repaired route. Replay the same frozen Academic Research Skills analysis and compare the result with the recorded failures.

Boundaries

  • Do not modify the reviewed Academic Research Skills repository or choose a side in its unresolved persistent-FAIL conflict.
  • Do not make cache/ the sole carrier of an authoritative result.
  • Do not retain every run permanently without a named consumer and retention rule.
  • Do not collapse the full typed result into its compact kb/agentic-systems/ projection.
  • Do not generalize a reusable run framework without a second worked consumer.
  • Preserve unrelated worktree changes and use explicit owned paths.
  • Land separable code, contract, documentation, and replay evidence in atomic commits; do not use one omnibus commit merely because this plan coordinates them.

Executor's decision authority

The executor may choose investigation order, fixtures, temporary formats, module boundaries, and whether the smallest adequate enforcement is a checked record, helper command, validator extension, or narrower instruction change. It may classify an observed event as successful recovery rather than a defect when the recorded protocol and result support that conclusion. It may discard a candidate mechanism when replay evidence shows unnecessary complexity or a second authority source.

The executor may select the canonical carrier when current consumers and the reports contract discriminate among the options. A choice that creates load-bearing state, changes default retention, or binds future transfer scans must be recorded at the appropriate decision surface before implementation. If the evidence leaves materially different retention policies equivalent, return those alternatives to the operator rather than selecting by convenience.

Initial route

The stages are ordered only where one supplies evidence or authority needed by the next. Within each stage, choose means from the live code and observed run.

Stage 1 — establish the failure baseline

Reconstruct each reported event from retained evidence where possible. Record its owner, exact failed invariant, residual risk, and whether prevention is required. In particular, distinguish zero analysed subjects from zero frontmatter-free text files, and distinguish premature lens dispatch from a valid packet invalidated by later same-boundary evidence.

Stage output: a bounded change set and the evidence gaps that no patch may claim to fix.

Stage 2 — decide canonical-result lifecycle

Trace the exact result's consumers through operator handoff, compact publication, transfer scanning, audit, and regeneration. Test the admissible carriers against the reports and agentic-systems collection contracts. Fix the canonical identity, retention, cleanup, projection lineage, and response behavior; capture an ADR if the choice binds future runs beyond the instruction.

Stage output: one lifecycle invariant that an executor and validator can check.

Stage 3 — implement the smallest enforcing route

Make the required phase, source, validation, routing, retention, and diagnostic effects operative. Add focused tests at the enforcement points and update only the contracts and operator documentation needed to make the shipped behavior coherent.

Stage output: a run cannot advance through a missing phase boundary or finish after losing its declared canonical result.

Stage 4 — replay, reconcile, and hand off

Run the workflow against Academic Research Skills commit 94436237913091d4739870159d241660527e8338. Verify the exact typed result, carrier, digest where required, compact projection relationship, and worktree containment. Compare every original failure with the replay and classify it as prevented, safely recovered, unchanged external evidence, or still unresolved.

Stage output: retained acceptance evidence and a precise disposition of every failure; later generalization or upstream repair remains separate work.

Feedback and return of control

Return to the operator when:

  1. no named consumer justifies a local canonical carrier under the existing retention contracts;
  2. the smallest adequate repair requires a generic run framework or a decision owned by another workshop;
  3. the original validation behavior cannot be reconstructed, so only better evidence capture—not a claimed behavioral fix—is warranted; or
  4. completion requires credentials, mutation of an external repository, or overwriting unrelated work.

These are decision boundaries, not approval checkpoints for ordinary implementation choices.

Acceptance evidence

  • output authority and canonical physical form are fixed before analysis;
  • the exact canonical result survives handoff in its declared carrier and satisfies that carrier's retention contract;
  • source revision, archive identity, source root, register versions, packet versions, and corrections remain resolvable;
  • validation proves one intended agentic-system-analysis-result with no failures and cannot be mistaken for a zero-subject success;
  • the compact collection artifact is traceable as a projection but is not silently substituted for the canonical result;
  • the replay preserves the source-side conflict as bounded uncertainty while introducing no moving-head or unobserved-operation claims;
  • unrelated worktree paths remain untouched; and
  • changed Python passes focused and complete tests plus Ruff, while changed KB artifacts and lifecycle state pass their relevant deterministic validation.

Later horizons

This mission does not own an upstream Academic Research Skills patch, a generic analysis-run framework, the memory-review corpus migration, or a cross-system comparison pipeline. A later commission may use the replay evidence to justify one of those expansions.