Contracts

adversarial-evidence-contract.md

Contract: Adversarial Evidence Disposition (v1)

Purpose

Define how adversarial-squad findings are captured for this mission's security-layer decisions.

Scope Decision

Resolved by decision 01KZBMQ8WBDZMQS9CFKTGARRJA:

  • Mandatory in plan/research artifacts
  • Mandatory in review-facing artifacts

Evidence Record Shape

Each challenged security finding must have an explicit disposition record containing:

  • finding_id: stable identifier in local artifact context
  • challenge_summary: what was challenged
  • source: adversarial pass / reviewer challenge
  • disposition: one of
  • accepted
  • changed
  • deferred_with_rationale
  • rationale: required for deferred_with_rationale, recommended otherwise
  • evidence_location: path/section where resulting change or acknowledgment is captured

Normative Rules

1. No contested security finding may be silently dropped. 2. Every disposition is explicit and traceable to an artifact location. 3. v1 remains advisory cadence: missing evidence is governance-noncompliant but does not introduce a new fail-closed transition gate handler in this mission.

Out of Scope

  • Runtime orchestration dependency on squad tooling.
  • Automatic cross-repo evidence sync.
  • Mandatory hard-gate enforcement at lane transition level.

security-checks-layer-contract.md

Contract: Security Checks Layer Wiring

Purpose

Define the minimum behavior contract for integrating the supply-chain security layer into software-dev workflow resolution surfaces.

Contract Scope

1. Directive contract 2. Tactic contract 3. Action index binding contract 4. Step-contract sequencing contract 5. Profile binding contract

Normative Rules

Rule 1 — Directive existence and scope

  • A directive with ID 051-supply-chain-install-safety exists in built-in directives.
  • It covers, at minimum:
  • official registry authenticity checks
  • package age/recency visibility
  • deny-by-default lifecycle script policy
  • Node Active LTS awareness and skew disclosure
  • incident-list and IoC posture guidance

Rule 2 — Tactic availability

  • A tactic supply-chain-install-safety exists and is referenceable from software-dev action indexes and targeted profile guidance.
  • dependency-hygiene remains available and is extended to include JS/TS concerns.

Rule 3 — Action binding completeness

For mission type software-dev, action indexes for:

  • plan
  • implement
  • review

must each include at least one security-layer artifact introduced by this mission.

Rule 4 — Step-contract security stages

Plan/implement/review step contracts include explicit security stages that delegate to the security directive/tactic layer.

Rule 5 — Advisory compatibility

  • No new fail-closed transition gate handler is introduced by this mission.
  • Existing transition behavior remains compatible while guidance/evidence obligations increase.

Rule 6 — Profile coverage

Targeted profiles include security-layer references and expectations:

  • reviewer-renata
  • implementer-ivan
  • node-norris
  • frontend-freddy
  • python-pedro
  • java-jenny
  • architect-alphonso

Verification Hooks

Minimum verification evidence:

1. Action context resolution output includes new layer for plan/implement/review. 2. Step contract files show explicit security stages. 3. Profile resolution or profile YAML shows required references. 4. Tests prove at least one path each for action binding, step-contract binding, and profile binding.