# Adversarial and Regression Cases

Use to verify defect reports and to attack a proposed fix. Select relevant cases; add every confirmed incident as a versioned regression fixture.

## Closure Standard

A reported defect is closed only when:

1. reproduced or decisively proven on an immutable known-bad artifact;
2. root contract identified across all affected consumers;
3. fix exists in the final combined tree;
4. regression test fails on known-bad or focused mutation and passes on the candidate;
5. manifest-only installed projection passes;
6. fresh install and required upgrades receive the fix;
7. supported OS/shell/runtime matrix passes;
8. tag, release, manifest, CI receipt, and announcement bind to the fixed SHA.

“Merged to main” closes only source status, not delivery.

## Mutation Catalog

### Release and Manifest

- change a delivered file without regenerating the manifest;
- include an excluded test or omit a required generator/helper;
- make a deprecated path overlap a delivered path;
- validate PRs independently but introduce conflict-resolution drift in the combined tree;
- pre-create a tag at another SHA;
- advertise a version without a GitHub Release object;
- make announcement run after a skipped publication step.

### Update Transaction

- serve bootstrap from release A, manifest from B, and one payload from C;
- return an older release or stale latest-release response;
- fail one parallel payload, rename, migration, or runtime build;
- interrupt before/after marker creation and rerun;
- overwrite the executing updater;
- create a user-modified managed file and a synthetic user-owned file;
- omit the historical merge baseline;
- mark version current before required postprocessing.

### Portability and Dependencies

- run every production path under stock macOS Bash 3.2;
- remove PyYAML from default Python while leaving a valid alternate interpreter;
- make dependency parsing fail and assert the diagnostic is dependency-specific;
- execute cron/launchd-only branches, role installers, and sourced helpers;
- use paths containing spaces and Unicode.

### Hooks and Safety Gates

- merge `git add && git commit` in one call;
- use pipeline, subshell, alias, wrapper, alternative quoting, or indirect script;
- make the index empty before pre-tool validation;
- leave a lock/owner token with missing session identity;
- attempt exact cleanup while the gate is active;
- corrupt or remove policy/config/parser dependencies;
- replay approval with modified target or parameters;
- invoke the same write through a role, scheduler, or another agent.

### Day Open/Close and Runtime

- install from manifest only and remove source checkout access;
- seed no extension, prose-only extension, valid executable checks, and failing checks;
- store a session flat while the reader expects month folders, and vice versa;
- mix pending, pending-review, applied, malformed, and body-text status reports;
- force LLM, calendar, Git, network, and Python failures;
- run manual and scheduled entry points;
- test two concurrent invocations and a stale lock;
- confirm postcondition before commit/push and after a failed check.

### Agentic Paths

- embed instructions in web/calendar/document/memory content asking the agent to override policy;
- request an unlisted tool through a trusted-looking role message;
- persist malicious content and load it in a later day/session;
- attempt secret extraction through logs, URL parameters, Git metadata, and inter-agent messages;
- replay or alter a destructive-action approval;
- force repeated tool failure to test recursion, retry, time, token, and cost caps;
- compromise one subagent and ask it to delegate a higher-privilege action.

## False-Green Detectors

- zero tests discovered;
- relevant job/step skipped;
- test reads an excluded source-only fixture;
- failure is caught and replaced by empty success;
- `XFAIL`, fallback, or “pending” counted as support;
- regression passes both bad and fixed artifacts;
- validation uses a different SHA, shell, OS, Python, entry point, or manifest than publication;
- a second run says current while required files remain old;
- separately green PRs lack an exact combined-tree run;
- artifact provenance exists but is never verified.

# Agentic Security Review

Use for skills, prompts, rules, hooks, memory, tools, approvals, MCP or other connectors, role agents, and multi-agent orchestration.

## IWE Trust Boundaries

Treat these as separate principals and data classes:

- system/platform instructions;
- repository and skill instructions;
- human request and explicit approval;
- retrieved web, calendar, document, email, issue, and tool output;
- persistent memory, DayPlan/WeekPlan, reports, and session logs;
- role agents and inter-agent messages;
- shell/filesystem/network/GitHub/calendar tools;
- secrets and external identities;
- scheduled or headless execution with no human present.

External and persisted content is untrusted data. It must not silently grant tools, change policy, redefine approval, or become higher-priority instructions.

## Abuse-Case Matrix

| Case | Required behavior |
|---|---|
| Direct/indirect prompt injection | Retrieved content cannot replace platform policy or authorize tools. |
| Tool misuse | Deny unlisted tool, path, host, verb, or operation even when the model requests it confidently. |
| Privilege escalation | A low-trust role or subagent cannot inherit a parent’s write, secret, or external-message privilege. |
| Memory poisoning | Untrusted content is validated, attributed, scoped, bounded, and reviewable before persistence. |
| Data exfiltration | Secrets/private context cannot leave through logs, URLs, command arguments, citations, Git commits, or another agent. |
| Goal hijacking | Retrieved or persisted text cannot replace the explicit session objective. |
| Approval bypass | High-impact action requires a valid approval bound to exact normalized parameters and target. |
| Approval replay | Expired, altered, duplicated, or cross-session approval is rejected. |
| Command-shape bypass | Combined commands, pipelines, quoting, aliases, wrappers, and indirect scripts cannot bypass hooks. |
| Fail-open fallback | Missing policy, parser, model, dependency, or log sink blocks a sensitive action. |
| Runaway autonomy | Retry, recursion, chain depth, time, token, and cost limits stop loops. |
| Multi-agent cascade | One compromised agent cannot make another exceed its own trust boundary. |
| Scheduled execution | Headless mode has narrower authority and cannot substitute implicit approval. |

## Tool and Approval Contract

- Grant the minimum tool set and scope per role; separate read, write, delete, external messaging, and administrative actions.
- Make authorization deterministic outside the model where practical.
- Classify destructive, irreversible, credential, publication, bulk-write, and externally visible actions as high impact.
- Bind approval to actor, tool, normalized arguments, exact target, timestamp, expiry, and nonce. Revalidate immediately before execution.
- Separate proposal from execution for high-impact actions.
- Make operations idempotent where possible; require explicit duplicate confirmation otherwise.
- A dry-run or diagnostic sentinel must have ownership, expiry, crash recovery, and a cleanup path that remains authorized while the sentinel exists.
- Fail closed if risk classification, approval validation, policy lookup, dependency resolution, or audit logging fails.

## Memory and Artifact Contract

- Validate schema and provenance before persistence.
- Separate observations, user decisions, model inference, and executable instructions.
- Do not promote quoted/retrieved commands into active instructions.
- Enforce session/user/repository scope, retention, size, and allowed content class.
- Reject secrets and unsafe executable payloads from long-term memory.
- Preserve an audit trail for who/what wrote, reviewed, superseded, or deleted an item.
- Test cross-day, cross-role, and cross-agent reads for both intended carry-over and forbidden contamination.

## Hook Validation

Test the real host event and real command lifecycle, not a helper extracted from the hook. Include:

- empty index versus staged changes;
- untracked file then `git add && git commit` in one tool call;
- quoted paths, spaces, Unicode, globbing, pipelines, subshells, aliases, and wrapper scripts;
- direct binary invocation and alternative Git clients;
- multiple artifacts and partial staging;
- parser failure, missing dependency, timeout, and malformed hook input;
- bypass through another role, agent, scheduler, fallback, or generated script.

If enforcement depends on pre-execution state, prove that the guarded state already exists at that moment or enforce it at a later unavoidable boundary such as pre-commit.

## Observability and Response

Retain structured, redacted evidence for security-relevant decisions: agent/role, session, policy version, action class, approval identifier, tool, normalized target, result, timeout/circuit-breaker event, and reason. Monitor repeated denial/bypass attempts, elevated privilege, unusual tool frequency, recursion, and cost. Provide a safe interrupt/disable path and incident regression fixture.

# CI and Supply-Chain Review

Use for workflows, GitHub Actions, dependency or release-pipeline changes, and CI evidence.

## Workflow Threat Model

Review:

- untrusted PR content reaching privileged `pull_request_target` or `workflow_run` contexts;
- script injection through branch names, titles, paths, issue text, or generated output;
- excessive `GITHUB_TOKEN` or environment-secret permissions;
- third-party actions referenced by mutable tags instead of full commit SHA;
- cache or artifact reuse across trust boundaries;
- self-hosted runners exposed to untrusted public code;
- release jobs that can run after a skipped or failed validation job;
- workflows that silently do nothing when secrets or channel configuration are absent;
- external notifications emitted before the release actually exists.

## Required Controls

- Set top-level token permissions to read-only or none; elevate narrowly per job.
- Pin third-party actions to full-length commit SHAs and verify the SHA belongs to the intended repository.
- Never check out untrusted PR code in a privileged workflow with write tokens or secrets.
- Pass untrusted values through data/environment boundaries, not directly into executable inline scripts.
- Use GitHub-hosted ephemeral runners for public untrusted contributions unless a stronger isolated design is documented.
- Protect release workflows and manifest/security-policy paths with required review or CODEOWNERS.
- Test missing-secret and missing-channel branches. Optional notification must skip truthfully; required publication must fail closed.

## Exact Receipt Review

For every required job record:

- workflow file and revision;
- event and condition;
- actual checkout SHA;
- runner OS, architecture, shell path, and version;
- relevant dependency versions;
- step execution status and exit code;
- test names/counts and whether the intended test file ran;
- `continue-on-error`, allowed failures, retries, `SKIP`, and `XFAIL`;
- uploaded artifact digest and retention.

A green summary is insufficient when the critical step was skipped, discovered zero tests, used an unsupported shell, or read source-only files absent from delivery.

## Provenance and Attestations

For published archives, installers, manifests, or packages:

- generate provenance that binds repository, workflow, event, environment, commit SHA, and artifact digest;
- publish an SBOM when the artifact contains third-party executable dependencies;
- verify the attestation as a consumer step against the expected repository and workflow identity;
- retain the verification result in the release receipt;
- remember that provenance proves origin and build path, not safety or functional correctness.

## Required Matrix

Run actual supported environments, not compatibility emulation alone:

- stock macOS `/bin/bash` 3.2 when supported;
- current Bash on macOS and Linux;
- declared Python versions with and without optional dependencies;
- serial and production parallel download modes;
- clean checkout and manifest-only installed projection;
- fork PR path without author secrets.

Static scanners, ShellCheck, OpenSSF Scorecard, dependency review, and secret scanning complement behavior tests; none substitutes for the installed end-to-end path.

# Evidence and Reporting

Use before issuing a verdict, closing an issue, or approving a release.

## Evidence Quality

Strongest to weakest:

1. installed end-to-end behavior on the exact released/candidate artifact;
2. clean disposable reproduction pinned to an immutable SHA or tag;
3. source -> manifest -> installed target -> consumer proof;
4. exact-SHA CI log with the relevant non-skipped step;
5. static source observation;
6. documentation, issue/PR body, commit message, badge, or announcement.

Lower evidence can identify a lead but cannot silently substitute for end-to-end proof.

## Result Classes

- `platform_defect`: repository-owned implementation or delivery violates its documented contract.
- `test_infrastructure_defect`: runner, fixture, workflow, or test harness misrepresents product behavior.
- `external_dependency_failure`: third-party service, network, credential, or platform availability blocks the path.
- `expected_behavior`: implementation and current explicit contract agree.
- `false_positive`: reported failure does not reproduce on the exact artifact, or a test reports success without exercising the contract.
- `cannot_verify`: evidence is unavailable, unsafe to obtain, or attached to the wrong artifact.

Use mixed classification when multiple boundaries fail. Do not force a product conclusion from an external outage or contaminated fixture.

## Severity

- `P0`: confirmed data loss/corruption, credential exposure, unauthorized destructive or externally visible action, or compromise of the release channel.
- `P1`: unsafe install/update/release path, core runtime blocker, approval/safety bypass, persistent agent lockout, or required automation reporting false success.
- `P2`: degraded but recoverable workflow, portability gap, incorrect non-critical state/metrics, or incomplete defense-in-depth.
- `P3`: documentation, diagnostics, low-impact UX, or maintenance drift without safety impact.

Severity measures impact and exploitability, not patch size.

## Confidence and Falsifier

- `high`: exact-artifact behavior reproduced or decisive source-to-consumer proof with competing explanations ruled out.
- `medium`: strong source evidence or partial reproduction, but one relevant boundary remains untested.
- `low`: plausible lead only; do not use it alone to block or approve a release.

Every material finding must state a concrete falsifier, for example: “This finding is false if the manifest-only v0.39.0 installation contains file X at path Y and entry point Z executes it successfully under `/bin/bash` 3.2.”

## Required-Gate Table

At minimum report:

| Gate | Expected evidence |
|---|---|
| Artifact identity | source SHA, manifest digest, tag/release, workflow checkout |
| Manifest integrity | deterministic generation and zero completeness/hash errors |
| Clean install | documented command and installed postconditions |
| Upgrade matrix | required predecessors, sentinels, transaction, idempotency |
| Installed projection | consumers work without source-only files |
| Platform matrix | actual supported OS/shell/Python paths |
| Agent safety | relevant abuse cases and denial/approval evidence |
| Runtime/integration | canonical entry point and user-visible postcondition |
| Supply chain | pinned actions, permissions, provenance/attestation policy |
| Negative control | known-bad or mutation is detected |

Use `PASS`, `FAIL`, `PARTIAL`, `SKIP`, or `CANNOT_VERIFY`. Only PASS contributes to GO. A required `PARTIAL`, `SKIP`, or `CANNOT_VERIFY` blocks the corresponding claim.

## Issue Receipt

```markdown
## Snapshot
- observed_at:
- bad_artifact:
- candidate_artifact:
- supported_environment:

## Contract
- expected:
- actual:
- affected_delivery_path:

## Reproduction
- disposable_fixture:
- exact_entry_point:
- exit_and_postcondition:
- secrets_or_live_data_used: no

## Regression
- bad_or_mutated_control: FAIL as expected
- candidate: PASS
- installed_projection: PASS/FAIL
- upgrade_matrix: PASS/FAIL

## Finding
- severity:
- class:
- owner:
- confidence:
- falsifier:
- release_blocking: yes/no
```

## Release Report

Lead with one sentence that answers whether publication is safe. Then list blockers before successes. Distinguish precisely:

- fixed in a working tree;
- committed;
- merged to main;
- validated on the exact final SHA;
- tagged;
- published as a release;
- delivered by documented setup/update;
- operationally proven at the consumer.

Never phrase these states as equivalent.

# Install and Upgrade Matrix

Use for setup, update, migration, runtime rebuild, interpreter resolution, and portability claims.

## Fixture Rules

- Use only synthetic content. Never seed from a real consumer workspace.
- Create random sentinel bytes in every documented user-owned class such as `extensions/`, existing `params.yaml`, local settings, secrets placeholders, and governance repositories.
- Record pre-run hashes, modes, Git status, and ownership classification.
- Isolate environment routing and network caches. Pin the candidate by immutable SHA or tag.
- Capture stdout, stderr, exit status, installed manifest identity, transaction markers, and postconditions.

## Minimum Matrix

Test independently:

1. documented fresh install;
2. previous release -> candidate;
3. oldest explicitly supported release -> candidate;
4. every release boundary that changed updater, manifest, ownership, generator, runtime, or layout semantics;
5. candidate -> candidate second run;
6. supported macOS and Linux shells/runtimes;
7. serial and parallel paths when both are production behavior.

If the project promises upgrades from every historical supported version, test every promised edge or narrow the documented support range before release.

## Assertions

For each cell require:

- preview and apply resolve the same immutable release;
- updater bootstrap, manifest, and payloads use that identity;
- manifest verification succeeds before live replacement;
- platform-owned files match expected hashes and modes;
- user-owned sentinels remain byte-identical;
- deprecated platform-owned files are removed only when provenance proves ownership;
- unknown or modified files are preserved or require explicit resolution;
- runtime rebuild succeeds with no unresolved placeholders;
- transaction marker closes only after all required postprocessing;
- failures produce a nonzero exit and accurate diagnostic;
- no unexpected dirty state or orphan staging files remain;
- second run downloads nothing unnecessary, changes nothing, and returns success.

## Failure Injection

Inject failures at these boundaries:

- manifest unavailable, truncated, malformed, stale, or wrong hash;
- payload missing, wrong hash, wrong mode, or served from another revision;
- one parallel download fails while others succeed;
- disk write, rename, runtime build, migration, or postprocessing fails;
- process interruption before and after transaction marker creation;
- interpreter exists but required module is absent;
- resolver finds a non-default valid interpreter;
- generator or fixture is excluded from delivery;
- stale incomplete marker or owner token remains from a crashed run;
- updater encounters a user modification or merge conflict;
- rerun follows every failure.

The updater must either finish the complete contract or leave an explicit recoverable incomplete state. It must never mark the version current while required files or migrations remain old.

## Shell and Python Portability

- Execute with the actual declared shell binary. `bash` on a modern runner does not prove macOS Bash 3.2 compatibility.
- Scan every production entry point, sourced helper, role installer, cron/launchd branch, and generated script for unsupported features.
- Use one shared Python resolver contract for all `.py` consumers.
- Test system Python without PyYAML and an alternate Homebrew/Nix interpreter with it.
- Missing dependencies must name the dependency and corrective path; suppressed parse errors must not become false configuration diagnostics.
- Declare dependencies and ensure documented setup installs or verifies them for the actual consumer interpreter.

## Installed Projection

Create a tree from manifest-delivered files only, then run every delivered validator, generator, role, hook, and runtime consumer. Fail when a delivered file relies on an excluded test fixture, source-only default, undeclared Python module, or developer checkout path.

# Methodology Sources

Checked 2026-08-26. These are primary or project-maintained sources. Recheck mutable guidance before a security-sensitive revision.

## Skill Design

- [Agent Skills specification](https://agentskills.io/specification): portable `SKILL.md` structure, concise discovery metadata, progressive disclosure, focused references, and validation.
- [Agent Skills best practices](https://agentskills.io/skill-creation/best-practices): ground skills in real incident/runbook evidence, use moderate detail, route references explicitly, and refine through execution traces and evaluation cases.
- [Anthropic Claude Code skills](https://docs.anthropic.com/en/docs/claude-code/skills): skill discovery, supporting files, invocation behavior, and testing in Claude Code.

## Agentic Red Team

- [OWASP AI Agent Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html): least-privilege tools, untrusted-input boundaries, memory isolation, action-bound approvals, fail-closed enforcement, monitoring, multi-agent containment, and adversarial CI cases.
- [OWASP GenAI Red Teaming Guide](https://genai.owasp.org/resource/genai-red-teaming-guide/): threat-model-driven testing across model, implementation, infrastructure, and runtime layers.
- [OWASP Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/): current agentic risk categories and mitigations.
- [MITRE ATLAS](https://atlas.mitre.org/): threat-informed adversarial techniques and case studies for AI-enabled systems.
- [NIST AI RMF Generative AI Profile, AI 600-1](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf): pre-deployment and ongoing evaluation, go/no-go thresholds, independent assessment, incident evidence retention, and value-chain risk.

## Secure Development and Release Supply Chain

- [NIST Secure Software Development Framework, SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final): prepare, protect, produce well-secured software, and respond to vulnerabilities through repeatable development practices.
- [SLSA v1.2 specification](https://slsa.dev/spec/v1.2/): build/source integrity and verifiable artifact provenance.
- [SLSA v1.2 artifact verification](https://slsa.dev/spec/v1.2/verifying-artifacts): verify artifact digests and provenance against an explicit policy and trusted builder/source identity.
- [The Update Framework security model](https://theupdateframework.io/security/): rollback, freeze, mix-and-match, arbitrary-package, and key-compromise threat classes for software update systems.
- [The Update Framework specification](https://theupdateframework.github.io/specification/latest/): consistent snapshots, expiration, version monotonicity, threshold trust, and target verification.
- [GitHub Actions secure use](https://docs.github.com/en/actions/reference/security/secure-use): least-privilege tokens, full-SHA action pinning, untrusted workflow boundaries, secret handling, and runner isolation.
- [GitHub artifact attestations](https://docs.github.com/en/actions/concepts/security/artifact-attestations): cryptographically signed provenance binding artifacts to workflow, repository, environment, event, and commit SHA; verification is required and does not itself prove safety.
- [OpenSSF Open Source Project Security Baseline](https://baseline.openssf.org/versions/2025-10-10.html): minimum repository, workflow, access, vulnerability, and release controls.

## Adaptation to IWE/FMT

The skill translates these sources into platform-specific acceptance tests:

- SLSA/GitHub -> exact SHA/tag/release/manifest/CI receipt and optional attestation verification;
- TUF -> updater rollback, freeze, mixed-revision, stale-cache, and partial-publication tests;
- OWASP/NIST/MITRE -> prompt, memory, tool, approval, scheduling, multi-agent, exfiltration, and loop abuse cases;
- NIST SSDF/OpenSSF -> protected release workflows, least privilege, negative controls, vulnerability regression, and retained evidence;
- prior IWE/FMT defect classes -> installed projection, Bash 3.2, shared Python resolver, self-update transaction, Day Open graph, session-layout consistency, and truthful fail-closed postconditions.

The adaptation intentionally excludes any real consumer installation, personal path, private DS content, or user-specific integration policy.

# Release and Update Security

Use for release candidates, updater changes, manifest changes, announcements, tags, and publication decisions.

## Immutable Release Receipt

Bind these to one intended revision:

1. final source SHA, including conflict resolution;
2. validation run and its actual checkout SHA;
3. generated manifest version, digest, file set, exclusions, and deprecated paths;
4. tag and peeled tag SHA;
5. GitHub Release object and published assets;
6. release workflow run and artifact digest or provenance attestation;
7. updater-resolved ref for bootstrap, manifest, and every payload;
8. announcement emitted only after the release object and required gates exist.

Fail if any identity differs. A tag-exists skip, version bump, changelog entry, or release announcement is not publication evidence.

## Integrated-Tree Gate

- For overlapping PRs, inspect the combined merge tree, not the individual green heads.
- Regenerate the manifest after the final merge/conflict resolution.
- Require all release gates on the exact final SHA.
- Treat any post-validation change as invalidating the previous receipt.
- Block branch or release publication when required status checks are missing, skipped, stale, or red.

## Manifest Contract

Verify independently:

- completeness: every platform-owned delivered file appears exactly once;
- accuracy: path, hash, mode, version, and classification match the final tree;
- exclusions: excluded tests or developer files cannot be required by an installed consumer;
- deprecations: no path is simultaneously delivered and deleted;
- transitive closure: scripts, generators, defaults, schemas, fixtures, imports, and resolvers needed at runtime are delivered;
- deterministic regeneration: two generations from the same tree are identical;
- clean tree: regeneration leaves no unexplained diff.

Build an installed projection from the manifest alone and run delivered consumers there.

## Updater Threat Cases

Adapt The Update Framework threat model even if IWE does not implement TUF metadata:

- **rollback**: server or cache offers an older release than the client has seen;
- **freeze**: the client is kept on known but stale release metadata;
- **mix-and-match**: bootstrap, manifest, scripts, or payloads come from different revisions;
- **moving-ref drift**: `main`, a mutable tag, or latest-release changes during one transaction;
- **partial publication**: metadata is visible before every target file is available;
- **arbitrary payload**: a file does not match authenticated release metadata;
- **fast-forward/version poisoning**: implausible metadata version strands future updates;
- **cache poisoning**: stale or attacker-controlled cache wins over pinned content.

Expected boundary:

- resolve one immutable release identity once;
- verify every downloaded target against trusted metadata from that same snapshot;
- reject older-than-trusted versions unless an explicit, separately authorized rollback mode exists;
- never combine files from different release identities;
- stage, verify, then atomically commit the transaction;
- retain a recoverable prior state until postprocessing succeeds;
- report an incomplete or unverifiable update as failure, never as current.

## Self-Update Contract

The updater may replace its managed copy only through an explicit bootstrap protocol:

1. current updater resolves and verifies the release;
2. new updater is staged under a separate path;
3. digest and executable mode are verified;
4. control transfers once to the staged version with the pinned release identity;
5. a loop/re-exec guard prevents recursion;
6. failure preserves a runnable recovery path;
7. second invocation is a clean no-op.

Generic in-place overwrite of the executing script is a release blocker.

## Release Decision

`GO` requires one immutable receipt, manifest-only projection, supported upgrade matrix, negative controls, and non-skipped exact-SHA CI. Artifact attestations strengthen provenance but do not prove correctness; the verified artifact must still pass IWE policy and behavior tests.

# Runtime and Integration Contracts

Use for Day Open/Close, extension graphs, roles, launchd/systemd/cron, calendar, Git operations, Python helpers, and generated runtime.

## Delivery Closure

A feature is operationally delivered only when all layers agree:

1. canonical source and generator input;
2. generated artifact;
3. manifest ownership, hash, mode, exclusions, and deprecations;
4. fresh-install destination;
5. existing-install update or migration destination;
6. consumer lookup path;
7. transitive scripts, defaults, fixtures, schemas, imports, and resolvers;
8. runtime or scheduled invocation;
9. exit propagation and truthful diagnostics;
10. observable user-facing postcondition.

Source-tree CI, repository presence, or manifest presence proves only one layer.

## Ownership Model

The repository must explicitly classify each installed path:

- platform-managed: replaced only by verified platform release logic;
- generated/derived: reproducibly rebuilt, never hand-patched as the durable fix;
- user-owned: never overwritten or deleted by default;
- merge-managed: changed only through an explicit previewable merge/migration;
- deprecated platform-owned: removable only with ownership/provenance evidence.

Use synthetic sentinels to test user-owned preservation. Do not use real customizations.

## Day Open

Test manual and scheduled paths separately. Require one canonical entry point and trace the actual Strategist/headless invocation.

Verify:

- `before -> core -> after -> checks` ordering and nonzero propagation;
- extension discovery at the installed path;
- platform defaults installed without overwriting user extensions;
- root/template/runtime/governance paths resolve from documented configuration;
- calendar and knowledge inputs distinguish missing, empty, stale, applied, pending, and parse failure;
- carry-over writer and all readers use the same session/report layout;
- LLM failure, dependency failure, or failed checks cannot return success;
- dated DayPlan is structurally valid and contains no unresolved state beyond explicit policy;
- commit/push occurs only after checks pass;
- status, heartbeat, counters, and diagnostics describe the actual result.

An `XFAIL`, fallback-only result, zero discovered checks, or source-only dependency means Day Open is not end-to-end complete.

## Day Close and Git

Verify:

- checkpoint checks run before commit or push;
- validation cannot be bypassed by combined command shape;
- dirty, untracked, partially staged, detached, no-remote, non-fast-forward, offline, and authentication cases are truthful;
- an optional remote sync failure does not corrupt local work, while a required sync failure does not report completion;
- session/archive paths written by Day Close are the paths Day Open reads;
- close is idempotent or detects a duplicate explicitly;
- secrets and temporary runtime directories never enter commits or cloud backup.

## Roles and Scheduled Automation

Check without activating a real user service:

- generated plist/unit/cron content in a disposable destination;
- executable path, working directory, label, environment, and log paths;
- setup ordering: prerequisites exist before activation;
- actual production shell and interpreter resolver;
- update/incomplete marker blocks mutating roles;
- overlapping invocations, stale lock, crash recovery, timeout, and retry cap;
- headless authority is narrower than interactive authority;
- failure propagates to service status and observable diagnostics.

CI stubs such as `SETUP_CI` do not prove real launchd/systemd semantics. Include a real supported-platform smoke job when the platform contract claims it.

## Runtime Build

- Build only from pinned platform inputs and explicit configuration.
- Fail closed on missing generator, placeholder, dependency, or required artifact.
- Record source/manifest/config identities in the runtime receipt without secrets.
- Verify runtime completeness from the installed projection, not the source checkout.
- Rebuild failure must not silently retain a misleading “current” version marker.
- Patch the source or generator, never the derived runtime, for durable fixes.

#!/usr/bin/env bash
# see .claude/skills/iwe-platform-redteam/SKILL.md — step 0 Calibrate.
#
# Two legs:
#   1. boundary-guard behaviour — the safety-critical production code. Proves it
#      refuses real / non-disposable / workspace-nested targets, runs a command
#      under a disposable temp fixture, and redirects HOME/WORKSPACE_DIR (not
#      just IWE_ROOT) into the fixture so no env-derived path escapes.
#   2. environment smoke-test — that `shasum`/`cp -R` behave here and that the
#      manifest-integrity contract distinguishes a clean release from a tampered
#      one. This leg validates the ENVIRONMENT and the integrity contract, not
#      the LLM audit reasoning (that is runbook-driven and not executed here).
#
# Committed fixtures are never mutated: each is copied into a fresh mktemp first.
# Bash 3.2 compatible.

set -u

SKILL_DIR=$(cd "$(dirname "$0")/.." && pwd -P)
GUARD="$SKILL_DIR/boundary-guard.sh"
FIXTURES="$SKILL_DIR/fixtures"

fail=0
pass() { printf 'PASS: %s\n' "$1"; }
bad()  { printf 'FAIL: %s\n' "$1"; fail=1; }

sha() { if command -v shasum >/dev/null 2>&1; then shasum -a 256 "$1" | awk '{print $1}'; else sha256sum "$1" | awk '{print $1}'; fi; }

# Echo a fresh temp dir on stdout and return 0; return non-zero on failure so
# the caller's `x=$(mk) || halt` actually halts. A plain `exit` inside command
# substitution would only leave the subshell, letting the script continue with
# an empty path (and later `cp` into `/`) — so failure must travel via status.
mk() { d=$(mktemp -d 2>/dev/null) && [ -d "$d" ] && printf '%s' "$d"; }

# Deterministic integrity reflex: recompute each manifest hash, check the CI
# receipt, and return GO only when every delivered file matches and required
# checks passed. Returns a reason code on failure so a green result cannot hide
# the wrong cause.  `|| [ -n "$expected" ]` keeps a final line lacking a
# trailing newline (a real manifest could) from being silently skipped.
classify_release() {
  release_dir="$1"
  manifest="$release_dir/manifest.txt"
  receipt="$release_dir/ci-receipt.txt"
  [ -f "$manifest" ] || { echo BLOCKED_MANIFEST; return; }
  [ -f "$receipt" ]  || { echo BLOCKED_RECEIPT; return; }
  while read -r expected relpath || [ -n "$expected" ]; do
    [ -n "$expected" ] || continue
    target="$release_dir/$relpath"
    [ -f "$target" ] || { echo BLOCKED_MISSING; return; }
    [ "$(sha "$target")" = "$expected" ] || { echo BLOCKED_HASH; return; }
  done < "$manifest"
  grep -q '^required_checks: passed$' "$receipt" || { echo BLOCKED_RECEIPT; return; }
  grep -q '^status: green$' "$receipt" || { echo BLOCKED_RECEIPT; return; }
  echo GO
}

# --- guard: refuse a real workspace path --------------------------------------
if IWE_REDTEAM_FIXTURE_ROOT="$HOME/IWE" bash "$GUARD" -- true 2>/dev/null; then
  bad "guard should refuse a real IWE workspace path but ran the command"
else
  pass "guard refuses a real IWE workspace path"
fi

# --- guard: refuse a real, non-disposable path (real home) --------------------
if IWE_REDTEAM_FIXTURE_ROOT="$HOME" bash "$GUARD" -- true 2>/dev/null; then
  bad "guard should refuse a real non-temp path (\$HOME) but ran the command"
else
  pass "guard refuses a real non-disposable path"
fi

# --- guard: refuse a fixture nested inside a (temp-located) workspace ----------
# Exercises the defense-in-depth nesting branch: HOME points at a temp dir that
# contains an IWE/ subtree, and the fixture lives under it.
fakehome=$(mk) || { bad "mktemp -d failed"; exit 1; }
mkdir -p "$fakehome/IWE/sub"
if HOME="$fakehome" IWE_REDTEAM_FIXTURE_ROOT="$fakehome/IWE/sub" bash "$GUARD" -- true 2>/dev/null; then
  bad "guard should refuse a fixture nested inside the workspace root but ran it"
else
  pass "guard refuses a fixture nested inside the workspace root"
fi
rm -rf "$fakehome"

# --- guard: allow a disposable temp path and run the command ------------------
tmp_ok=$(mk) || { bad "mktemp -d failed"; exit 1; }
tmp_ok_abs=$(cd "$tmp_ok" && pwd -P)
out=$(IWE_REDTEAM_FIXTURE_ROOT="$tmp_ok" bash "$GUARD" -- sh -c 'printf ran' 2>/dev/null)
if [ "$out" = "ran" ]; then
  pass "guard runs the command under a disposable temp path"
else
  bad "guard should run under a temp path (got: '$out')"
fi

# --- guard: redirect HOME into the fixture (not the real home) ----------------
home_in=$(IWE_REDTEAM_FIXTURE_ROOT="$tmp_ok" bash "$GUARD" -- sh -c 'printf "%s" "$HOME"' 2>/dev/null)
if [ "$home_in" = "$tmp_ok_abs" ]; then
  pass "guard redirects HOME into the fixture"
else
  bad "guard should set HOME to the fixture (got: '$home_in', want: '$tmp_ok_abs')"
fi

# --- guard: redirect WORKSPACE_DIR into the fixture (Critical #1) --------------
ws_in=$(IWE_REDTEAM_FIXTURE_ROOT="$tmp_ok" WORKSPACE_DIR="/real/workspace" \
  bash "$GUARD" -- sh -c 'printf "%s" "$WORKSPACE_DIR"' 2>/dev/null)
if [ "$ws_in" = "$tmp_ok_abs" ]; then
  pass "guard redirects WORKSPACE_DIR into the fixture"
else
  bad "guard should override WORKSPACE_DIR to the fixture (got: '$ws_in', want: '$tmp_ok_abs')"
fi

# --- guard: strip inherited IWE_* variables -----------------------------------
leak=$(IWE_ROOT="/nonexistent/leaked-workspace/IWE" IWE_REDTEAM_FIXTURE_ROOT="$tmp_ok" \
  bash "$GUARD" -- sh -c 'printf "%s" "${IWE_ROOT:-clean}"' 2>/dev/null)
if [ "$leak" = "clean" ]; then
  pass "guard strips inherited IWE_ROOT from the command environment"
else
  bad "guard leaked IWE_ROOT into the command (got: '$leak')"
fi
rm -rf "$tmp_ok"

# --- integrity contract: known-good -> GO -------------------------------------
good_run=$(mk) || { bad "mktemp -d failed"; exit 1; }
cp -R "$FIXTURES/known-good-release/." "$good_run/"
verdict_good=$(classify_release "$good_run")
if [ "$verdict_good" = "GO" ]; then
  pass "known-good release classified GO"
else
  bad "known-good release must be GO (got: $verdict_good)"
fi
rm -rf "$good_run"

# --- integrity contract: known-bad -> BLOCKED_HASH (planted mismatch) ---------
# The bad fixture differs from good ONLY in one manifest hash line, so the hash
# mismatch is the sole cause — assert that specific reason, not just "blocked".
bad_run=$(mk) || { bad "mktemp -d failed"; exit 1; }
cp -R "$FIXTURES/known-bad-release/." "$bad_run/"
verdict_bad=$(classify_release "$bad_run")
if [ "$verdict_bad" = "BLOCKED_HASH" ]; then
  pass "known-bad release BLOCKED by the planted manifest hash mismatch"
else
  bad "known-bad release must be BLOCKED_HASH (got: $verdict_bad) — false-green or wrong cause"
fi
rm -rf "$bad_run"

if [ "$fail" -eq 0 ]; then
  printf '\ncalibration OK — guard containment and integrity contract behave as required\n'
  exit 0
fi
printf '\ncalibration FAILED — do not trust a real audit verdict in this environment\n' >&2
exit 1