Frontier Infra

View saved version →

---
name: aar-attestation
description: Design, create, inspect, sign, verify, or integrate Agent Attestation Records (AARs) when agent work needs portable Ed25519-signed claims, independent verdicts, ground-truth status, and evidence commitments.
---

# Agent Attestation Records

Read `../../references/philosophy.md` for the signed-versus-true boundary and `../../references/threat-model.md` for verifier and secret risks.

Attest a target-runtime claim or outcome that the user has asked to make
portable. Do not issue an AAR for the coding assistant's patch, the plugin's
distribution, or SDK installation merely because this skill is available.

## Workflow

1. Fix the task claim and identify the subject, principal, verifier, verification method, independence class, and real-world source.
2. Run the check before deciding verdict or `ground_truth`; retain the raw result outside the model narrative.
3. Commit only necessary evidence: source, query/check, observation time, response hash, and a minimal non-sensitive excerpt.
4. Use the published tooling instead of inventing fields from memory: `npx -y @frontier-infra/audit` bundles the canonical AAR signer/verifier (`agentcontrolplane/tools/aar.mjs`); the spec lives in `frontier-infra/agentcontrolplane`.
5. Sign only through an operator-selected local key path and the discovered local tool. Never request, echo, copy, log, or bundle a private key. If key material was pasted into a prompt, transcript, issue, log, or other non-secret channel, treat it as exposed: refuse to use it, tell the operator to revoke or rotate it through their key-management process, and continue only with a newly provisioned key referenced by a local path or secret handle.
6. Verify the final bytes independently with the published verifier:

   ```sh
   npx -y @frontier-infra/audit verify --evidence evidence.json --aar aar.json --did-json did.json
   ```

   Signing during an audit run is `npx -y @frontier-infra/audit run <repo> --out <dir> --sign-key <private-jwk.json> --did-json <did.json>` — key material by local file path only.

7. Report the exact tool/schema source, signature validity when verified, AAR tier, evidence source, independence limitations, and any unverifiable claim. Keep the receipt and raw verification artifact linked but separately governed.

## Safety rules

- Do not write `verified` or `ground_truth: confirmed` until the actual check succeeded.
- Do not let the worker self-attest as the independent verifier.
- Keep evidence minimal and avoid credentials, personal data, and proprietary raw system output.

Referenced files: 1

View saved version →

---
name: avl-adoption
description: Design, build, review, validate, or package an Agent View Layer implementation so public sites expose discoverable machine-readable intent, state, and actions for agents and independent verifiers.
---

# Adopt Agent View Layer

Read `../../references/philosophy.md` when explaining why ground-truth views belong outside worker narrative.

## Workflow

1. Inspect the host and choose its native surface: route, CMS plugin, theme, extension, embed, or static document.
2. Inventory the human pages, agent companions, discovery signals, content negotiation, states, actions, schemas, and authorization boundaries.
3. Define what an independent verifier can observe without trusting the worker.
4. Implement the smallest native integration; preserve the host platform's permissions, escaping, lifecycle, and packaging conventions.
5. Validate with the published AVL CLI — `validate` for live URLs, `validate-file` for local files, `--level` to target a conformance rung:

   ```sh
   npx -y @frontier-infra/avl validate <url> --json
   npx -y @frontier-infra/avl validate-file <path> --json --level L3
   ```

6. Test direct discovery, Link headers/content negotiation where used, human rendering, agent rendering, auth-denied paths, and every declared action separately.
7. Report the validator output, achieved AVL level, exact evidence, and untested paths. A badge or `llms.txt` alone is not an AVL implementation.

## Security requirements

- Treat agent action declarations as public API documentation: validate inputs, enforce authorization server-side, and avoid exposing internal operations.
- Escape all user-controlled output by the host platform convention.
- Do not introduce hidden tracking, remote code, or automatic external calls.

Referenced files: 1

View saved version →

---
name: build-with-frontier-sdk
description: Build an application or agent harness with the published Frontier SDK packages. Use when implementing a governed agent system, wiring runtime health, agent-readable state, or signed receipts into a product, or when the user asks to use @frontier-infra packages, the Frontier SDK, or "build this the Frontier Infra way".
---

# Build with the Frontier SDK

The SDK is installable plumbing — use the published packages instead of
hand-rolling equivalents. If you find yourself writing a health reducer, an
agent-view generator, a receipt signer, or a conformance scorer from scratch,
stop: it ships.

You are the software developer using the SDK. You are not a worker, verifier,
operator, or subject inside the target application. Apply the requirements
below to the runtime being built, not to the interactive coding session.

| Package | Job | Get it |
|---|---|---|
| `@frontier-infra/protocol` | Four-layer runtime health record + deterministic fail-closed reducer (`evaluateRuntimeHealth`, `runtimeHealthExitCode`) | `npm install @frontier-infra/protocol` |
| `@frontier-infra/avl` | Agent-readable ground truth for your app; validator CLI (`validate <url>`, `validate-file <path>`, `--level`) | `npm install @frontier-infra/avl` |
| `@frontier-infra/audit` | Conformance scoring, evidence packets, AAR sign/verify (bundles the canonical `aar.mjs`) | `npx -y @frontier-infra/audit` |

## Application workflow

1. **Map the product** — inspect the target application's existing runtime,
   state, provider calls, effects, and failure modes. Choose only the Frontier
   capabilities it needs.
2. **Install the plumbing** — add the selected published packages as ordinary
   application dependencies. Preserve the application's package manager,
   framework, provider API, storage, and deployment conventions.
3. **Build the harness shape** — implement durable state, deterministic driver, fresh workers,
   single mutation gate (`machine-deployment` for the obligations). Do not
   design the loop from a blank page: clone the reference driver
   (`git clone https://github.com/frontier-infra/machine-driver`) and adapt
   its `driver.py` + `goal.json` contract to the deployment; `conductor-public`
   is the orchestrator-shaped starting point for ops/triage pipelines.
4. **Implement runtime contracts** — add contract proposal, ratification, and
   enforcement inside the target runtime when its workload needs bounded
   delegated work. Do not create a contract for the coding session by default.
5. **Ground truth** — emit an AVL view of real application state so verifiers
   read declared state, not the worker's narrative (`avl-adoption`).
6. **Health** — emit the four-layer health record; evaluate with the published
   reducer; aggregate must fail closed (`design-agent-governance`).
7. **Receipts** — sign target-runtime outcomes as AARs when the product needs
   portable proof and the operator
   provides local key paths (`aar-attestation`).
8. **Test the product** — run its ordinary unit, integration, failure, and
   runtime tests. If the user explicitly requests a conformance claim or the
   target's release criteria require one, audit the target deployment with
   `machine-conformance`; otherwise do not add an audit ceremony.

## Boundaries

- The builder is outside the target runtime. Host install prompts, tool
  permissions, commits, and the builder's own patch are not Frontier
  governance events unless the user deliberately installs that integration.
- The model is a replaceable worker; everything trustworthy lives in the
  target harness around its runtime model calls. If the target later invokes
  Codex or Claude through a worker adapter, those bounded invocations are
  workers; the coding assistant building the adapter is not.
- The object of governance is the application's agents — never the SDK's own
  supply chain. Do not build machinery that attests to package distribution:
  no vendored copies with hash locks, no bootstrap approval flows, no evals of
  your own paperwork. Host permission systems own install trust.
- Static audits never establish Machine-L3; live chaos evidence does.
- `same_principal` receipts are self-attestation — say so.

Referenced files: 1

View saved version →

---
name: conductor-pipeline
description: Design, adapt, implement, or audit a model-driven multi-agent triage and fulfillment pipeline using Conductor's fat-engine/thin-skill, closed-transition, fan-out/fan-in, persistent-workspace, human-gate, and delivery patterns.
---

# Adapt a Conductor-style pipeline

Read `../../references/pattern-catalog.md`, `../../references/system-architecture.md`, and `../../references/threat-model.md`. Treat this as an `orchestrator` shape unless the control loop is genuinely model-free. Current public Conductor material should be described as `Orchestrator-L1 Declared` unless newer executed evidence supports a different shape-stamped claim.

## Workflow

1. Define the item, sources, scoring rubric, threshold, research lanes, route values, deliverables, and the one human approval boundary.
2. Encode domain differences as validated configuration and templates. Keep dedup, bounds, thresholds, routes, dependency construction, persistence, retries, and legal transitions in a deterministic engine.
3. Keep model skills thin: detection, bounded scoring judgment, classification, synthesis, and proposal prose.
4. Use read-only scouts for untrusted sources; minimize each role's tools. Treat source content as prompt-injection input.
5. Build fan-out research lanes and a dependency-driven fan-in route. Persist the model-selected transition before effects so replay never calls the model again.
6. Use a shared persistent workspace for chained fulfillment. Put scope rails and a human gate immediately before the high-impact path.
7. Deliver proposals and results through an explicit channel action; a status change is not delivery.
8. Add cost gates, idempotency, terminal quarantine, failure alerts, and test cases per rubric boundary and route.

## Output

Return the configuration map, typed state/transition table, engine-versus-skill responsibility matrix, role/tool matrix, human-gate contract, security boundaries, and validation plan. Never claim `Machine-L*` for this shape.

Referenced files: 1

View saved version →

---
name: design-agent-governance
description: Design or review governance for an AI harness, including authority ceilings, verifier trust and freshness, mutation-path coverage, reversibility, human gates, operator override, audit receipts, budgets, escalation, and policy tests.
---

# Design agent governance

Govern the target application's runtime principals and effects. Do not treat
the coding assistant, its host permissions, or its implementation process as
part of that governance plane unless the user explicitly asks for a developer-
workflow integration.

Read `../../references/system-architecture.md`, `../../references/threat-model.md`, and `../../docs/runtime-health-contract.md`. Use `../../assets/governance-policy.yaml` and `../../assets/runtime-health-manifest.yaml` as starting artifacts.

## Workflow

1. Inventory every durable mutation, including message sends, model calls with spend, queue creation, filesystem writes, database updates, background jobs, and reads with side effects.
2. Assign each action a scope, base trust requirement, reversibility status, verified rollback reference when applicable, and human-gate rule when irreversible.
3. Define `effective_autonomy = min(operator_dial, contract_ceiling, scoped_verifier_trust)` and calculate the required trust before every effect.
4. Make missing/stale/unqualified verifier trust zero and missing reversibility irreversible.
5. Route every path through one gate or an expiring scope-bound gate token. Prohibit durable admin bypasses.
6. Define contract ratification, hash, scope, expiry, revocation, and immutable acceptance enforcement at the driver boundary.
7. Provide out-of-band operator halt and dial-down with an independent receipt sink and a measured effect SLO.
8. Define append-only governance events, budgets, ACK escalation, quarantine, health, and anomaly policies.
9. Model runtime health as four layers: `process`, `scheduler`, `execution`, and `governance`. Aggregate health must fail closed unless all four layers have fresh passing checks; a green process heartbeat must not mask a dead scheduler, blocked provider execution, or missing gate.
10. Validate sample health contracts with the published reducer when a JSON health artifact exists (`npm install @frontier-infra/protocol` in the project):

   ```sh
   node -e "import('@frontier-infra/protocol').then(async ({evaluateRuntimeHealth}) => console.log(JSON.stringify(evaluateRuntimeHealth(JSON.parse(require('fs').readFileSync(process.argv[1],'utf8'))), null, 2)))" <health-contract.json>
   ```

11. Write allow, deny, expired-verifier, forged-rollback, expired-human-gate, direct-bypass, and dead-workforce health tests.

## Output

Return the governance policy, mutation matrix, trust-role matrix, event schema, runtime health contract, override runbook, and negative-test plan. Distinguish policy prose from deterministic enforcement.

Referenced files: 1

View saved version →

---
name: design-agent-harness
description: Architect a new AI agent harness or redesign an unreliable loop, including trust roles, durable state, transition shape, worker isolation, verification, governance, ports, budgets, runtime health, threats, and evidence.
---

# Design an agent harness

Design the user's target application. The coding assistant is its architect
and implementer, not a runtime worker or governed subject.

Read these references before designing:

- `../../references/philosophy.md`
- `../../references/system-architecture.md`
- `../../references/pattern-catalog.md`
- `../../references/threat-model.md`

Use `../../assets/harness-design-dossier.md` as the output structure.

## Workflow

1. Define the user outcome, durable mutations, explicit non-goals, tolerated latency/cost, and failure history.
2. Classify the shape. Choose `machine` only when the driver can be model-free. Choose `orchestrator` when a model selects from a closed transition set and the choice is validated and write-ahead persisted.
3. Separate contract proposer, contract ratifier, worker, result verifier, operator, signer, and receipt sink. Record any unavoidable shared principal or failure domain.
4. Model durable states, allowed edges, terminal states, and exact persist-before-effect ordering.
5. Define narrow ports for queue, worker, verifier, state, governance, receipts, alerts, and ground-truth views.
6. Specify the contract grammar, context reconstruction, idempotency identity, budgets, quarantine, escalation, and override behavior.
7. Design governance with `design-agent-governance`; treat reversibility as verified data.
8. Add continuous component health, a watched watcher, anomaly fixtures, and a quarterly obligation retirement test.
9. Map each important claim to a self-test, chaos fixture, or external check. Keep the intended conformance claim `UNSCORED` until evidence exists.

## Output

Return the completed dossier, a short architecture decision summary, the first thin vertical slice, its acceptance/chaos tests, and the controls deliberately deferred. Flag assumptions that materially change trust or authority.

Make the target runtime's trust roles, mutation paths, state machine, and
verification source concrete enough to test, then implement the requested
slice. This design prerequisite does not ratify or govern the coding session.

Referenced files: 1

View saved version →

---
name: frontier-router
description: Explain Frontier Infra's philosophy, architecture, projects, terminology, and patterns; choose and compose the right components for AI harness, governance, agent-readable web, attestation, discipline, or reliable-operations work.
---

# Frontier Infra router

Use this as the teaching and routing entry point. Read the references that match the question:

- Philosophy or core claims: `../../references/philosophy.md`
- Six-box and governance architecture: `../../references/system-architecture.md`
- Reusable implementation patterns: `../../references/pattern-catalog.md`
- Project selection and maturity: `../../references/project-map.md`
- Adoption sequence: `../../references/adoption-journeys.md`

## Workflow

1. Resolve roles first. By default, the coding assistant is the developer and the user's product is the target application; do not cast the developer as one of the application's workers, verifiers, or governed subjects.
2. Identify the target application's outcome, durable effects, failure history, trust roles, and required autonomy.
3. Determine whether the user needs education, a design, an implementation, or an explicitly requested audit.
4. Select the smallest components that close those failure modes; distinguish standards from deployments and experiments.
5. State the intended target deployment shape: `machine`, `orchestrator`, or neither.
6. Separate what the target application will instruct, instrument, enforce, receipt, and independently verify.
7. Route implementation work to the focused skill and name the target artifacts and tests that will prove completion.

## Composition guide

- New harness architecture → `design-agent-harness`
- Application implementation with published packages → `build-with-frontier-sdk`
- Authority, mutation, reversibility, and override → `design-agent-governance`
- One bounded work contract → `goal-contract`
- Machine-shaped implementation → `machine-deployment`
- Evidence-based audit → `machine-conformance` (scoring runs `npx -y @frontier-infra/audit`; the sibling `frontier-audit` plugin's `audit-and-attest` skill covers the score-and-attest flow end to end)
- Model-driven domain pipeline → `conductor-pipeline`
- Site ground truth → `avl-adoption`
- Signed outcome evidence → `aar-attestation`
- Repository operations → `maintainer-gates`

## Boundaries

- Apply Frontier semantics to the target system. Do not govern, contract, audit, or attest the interactive builder's process merely because the plugin is present.
- Do not call an AAR's signature proof that the underlying claim is true; it proves who attested and what evidence was committed.
- Do not call a model-driven controller a Dumb Driver. Use the orchestrator shape and its lower guarantee ceiling.
- Do not call retries resilience without idempotency, budgets, quarantine, alerts, and kill/resume evidence.
- Do not route secrets or private operational configuration into public plugin assets.

Referenced files: 1

View saved version →

---
name: goal-contract
description: Turn a rough agent task or project increment into a bounded, independently ratifiable sprint contract with immutable acceptance checks, scope, constraints, autonomy ceiling, budget, escalation, identity, expiry, and receipt fields.
---

# Author a sprint contract

Use `../../assets/sprint-contract.yaml` as the artifact. Read `../../references/philosophy.md` for the two-layer independence rule.

This skill authors a contract for work that the target system will dispatch.
It may contract the current development task only when the user explicitly
asks for that outcome or an installed ADL/Proctor-style integration requires
it. Plugin presence alone is not such an integration.

## Workflow

1. Convert the request into one observable outcome. Separate desired effect from implementation method.
2. Enumerate in-scope and out-of-scope artifacts and mutations.
3. Write mechanically runnable acceptance checks against ground truth. Put prose review behind an explicit human or distinct-judge gate.
4. Declare constraints, allowed tools/effects, verifier scope/freshness, autonomy ceiling, attempt/time/token/cost budgets, and ACK escalation.
5. Identify proposer and ratifier. Leave status `DRAFT`, `ratified_by`, contract hash, and receipt empty until independent ratification actually occurs.
6. After ratification, hash the immutable contract, issue the receipt, set expiry, and make any acceptance change require revocation and a new contract version.

## Quality rules

- Avoid “works,” “looks good,” or “properly” unless a check defines them.
- Keep one contract small enough for one fresh-worker move or an explicitly decomposed set of moves.
- Set the ceiling to propose-only when verifier qualification or mutation coverage is incomplete.
- Do not fabricate ratification, timestamps, signatures, identities, or receipt references.

Return the contract plus a plain-language explanation of what can block, quarantine, escalate, or require human judgment.

Referenced files: 1

View saved version →

---
name: machine-conformance
description: Audit, score, or challenge an existing AI harness against Frontier Infra The Machine, determine Machine versus Orchestrator shape, run the canonical kit, gather evidence, design chaos tests, and prevent unsupported conformance claims.
---

# Audit Machine conformance

Read `../../references/conformance.md`, `../../references/system-architecture.md`, and `../../references/threat-model.md`.

Audit an explicitly identified target deployment. Do not automatically score
the repository being edited, the builder's process, this plugin, or the SDK's
distribution as a condition of using Frontier to build an application.

## Workflow

1. Audit the deployment wiring, not a standard, library, diagram, or README.
2. Determine shape from executed control flow: zero-token deterministic driver versus model-selected closed transitions with write-ahead decision persistence.
3. Inventory code/config for every box, governance control, foundation service, operational obligation, critical component, and mutation path.
4. Treat prose as a claim to test. Cite concrete file/config/runtime evidence.
5. Run the published conformance CLI — it bundles The Machine's static kit; do not hunt for a checked-out kit or recreate scoring logic:

   ```sh
   npx -y @frontier-infra/audit run <deployment-repository> --out <dir-outside-that-repo>
   ```

6. Execute or mark `NOT-RUN` the kill/resume, replay, lying-worker, verifier removal/staleness, duplicate effect, quarantine, budget, override, forged rollback, bypass, and dead-workforce health fixtures.
7. Verify receipt chains and health timestamps; confirm the audit sink survives operator halt of the deployment scope. If the deployment emits the four-layer runtime health contract, evaluate it with the published reducer (`npm install @frontier-infra/protocol`, then `evaluateRuntimeHealth(record)`) and treat any non-pass aggregate as fail-closed.
8. Report a deployment as a `structural candidate` when only static architecture/code mapping has been reviewed. Report a shape-stamped conformance level only when the required runtime evidence passes. Otherwise report current evidence, gaps, and the next lowest-cost falsifying test.

## Output

Return an obligation matrix with `PASS`, `FAIL`, or `NOT-RUN`; evidence locations; executed commands; limitations; spec/kit versions; and a dated claim or explicit `UNSCORED` verdict.

Referenced files: 1

View saved version →

---
name: machine-deployment
description: Implement, adapt, or harden a Frontier Infra Machine-shaped AI harness with a deterministic driver, durable state, fresh workers, independent verification, governance gates, budgets, quarantine, receipts, and runtime health.
---

# Deploy The Machine

Read `../../references/philosophy.md`, `../../references/system-architecture.md`, `../../references/pattern-catalog.md`, and `../../references/threat-model.md`. If the control loop asks a model to choose the next transition, stop and use `conductor-pipeline` or explicitly redesign it as an orchestrator shape.

You are implementing the target Machine, not participating in it as a worker.

## Target runtime contract

Implement or adapt a ratifiable work-contract capability in the target runtime with:

- one outcome-oriented definition of done;
- runnable acceptance checks and immutable constraints;
- an independently ratified contract (`ratified_by` differs from `proposed_by`) before the target runtime performs commit-capable work;
- worker-run and wall-time budgets;
- a conservative initial autonomy ceiling (`0` / propose-only).

Do not use `goal-contract` to gate the current coding task unless the user
explicitly asks to govern the development workflow or a real ADL/Proctor-style
integration already enforces it.

## Required deployment shape

1. Fill `../../assets/harness-design-dossier.md`; inventory every durable mutation path.
2. Define typed durable states, legal transitions, terminal quarantine, and write ordering.
3. Implement queue, worker, verifier, store, gate, receipt, alert, and ground-truth ports behind narrow adapters.
4. Persist before dispatch and before effects; enforce stable idempotency at the mutation store.
5. Start a new bounded worker for every attempt from contract plus current state, not transcript history.
6. Run contract checks in a distinct verifier and hard-deny success or mutation when it is absent, stale, or failed.
7. Evaluate operator dial, contract ceiling, scoped verifier trust, and verified reversibility at the single mutation gate.
8. Enforce attempt/resource budgets, acknowledgement escalation, terminal quarantine, and out-of-band override.
9. Emit receipts for transitions and gate decisions; publish health for every critical organ and the monitor itself.
10. Implement runtime health as four independent layers: process heartbeat, scheduler work-claim path, representative execution path, and governance gate path. Aggregate status must fail closed unless every layer passes a fresh check.

## Reference implementations

Start from the working deployments instead of a blank page: `machine-driver`
(github.com/frontier-infra/machine-driver) is the deterministic Box-2 driver
for code work with Machine-L2 evidence; `conductor-public` is the
orchestrator-shaped ops template. Adapt; do not reinvent.

## Target deployment verification

Run kill/resume, duplicate replay, lying-worker, missing/stale-verifier, forged-rollback, cap/quarantine, override, bypass, and dead-workforce health fixtures against the target deployment before claiming enforcement.

Validate runtime health with the published reducer — add `@frontier-infra/protocol`
to the deployment and evaluate records with `evaluateRuntimeHealth` /
`runtimeHealthExitCode`. When the user requests a conformance claim or the
target's release criteria require it, score the target deployment repository
with the published CLI, which bundles The Machine's static kit:

```sh
npx -y @frontier-infra/audit run <path-to-deployment-repo> --out <dir-outside-that-repo>
```

Treat the generated evidence packet as the source for conformance claims. Static implementation review establishes only a `structural candidate`; a README claim or a passing happy path does not establish a Machine level.

## Boundaries

- Start in propose-only mode; do not change to commit mode without a verified contract and operator authority.
- Requeue failed work only within a fixed budget; quarantine and surface repeated failures.
- Do not treat driver hash-chain logs as canonical AARs unless they are actually shaped, signed, and independently verified as AARs.

Referenced files: 1

View saved version →

---
name: maintainer-gates
description: Inspect, plan, apply, verify, or audit the Maintainer Gate Blueprint for multi-agent repositories that need governed issue/PR intake, clean promotion lanes, handoff evidence, deterministic CI gates, and operator validation.
---

# Adopt Maintainer Gates

Read `../../references/threat-model.md` when defining destructive-command and cross-tenant controls.

## Workflow

1. Inspect the target repository before writing anything. Identify its package manager, test/lint/typecheck commands, branch and release policy, CI system, production-risk commands, and existing contributor instructions.
2. Prepare a manifest from the Blueprint's example. Keep policy and generated paths specific to the target repository.
3. Generate and review a project-specific manifest. Before applying, show the target paths and any CI or hook files it will create or change.
4. Locate or provision the Maintainer Gate Blueprint before applying it. Prefer the target repository's documented vendored path or a checked-out `frontier-infra/Maintainer-Gate-Blueprint` repository. If `bin/apply-blueprint.mjs` is not present at the selected Blueprint root, stop with that prerequisite instead of invoking a plugin-local path.

   ```sh
   test -f <blueprint-root>/bin/apply-blueprint.mjs && node <blueprint-root>/bin/apply-blueprint.mjs <manifest.json>
   ```

5. Review every generated policy and command pattern against the actual repository. Tighten placeholders; do not ship generic production guards as if they were verified.
6. Run the Blueprint checks, target lint/typecheck/tests, gate allow/deny fixtures, handoff validation, and PR-intake validation.
7. Report separately: agent-read instructions, deterministic local hooks, CI gates, promotion/operator gates, and remaining manual controls.

## Rules

- Keep implementation work separate from clean dev/release reconstruction.
- Use commit/file evidence rather than branch names as truth.
- Never claim an operator validation or production outcome that has not occurred.
- Do not enable destructive production-command blocks without first confirming their patterns against the target environment.

Referenced files: 1