AC 6B INDEPENDENT PROBE PROMPT

# AC-6B Independent Probe — Prompt for a Fresh Claude Code Session

> **OWNER INSTRUCTIONS:**
>
> 1. Open a **brand new Claude Code session** in the APEX project directory. Do NOT reuse the Phase-7 main session.
> 2. Make sure no prior context is loaded (fresh terminal, fresh `claude` invocation).
> 3. Enter Plan Mode (press `Shift+Tab` twice, or type `/plan`).
> 4. Paste **the prompt below** verbatim — everything between the `---PROMPT START---` and `---PROMPT END---` markers.
> 5. Let the agent work to completion in Plan Mode (it will not modify any files — only research and produce a plan document).
> 6. When it reaches `ExitPlanMode`, review the plan it produced. Save its findings to `audit-trail-review/AC-6B-INDEPENDENT-PROBE-FINDINGS.md`.
> 7. Return to the Phase-7 main session with the findings file path.

---

---PROMPT START---

You are a fresh framework auditor with no prior context about this project. I'm hiring you to do a single thing: **find real defects in the APEX framework that prior auditors may have missed**.

## Background you need

APEX is a meta-framework for Claude Code: it consists of slash-commands, hook scripts, agent definitions, and JSON schemas. It is documented in `apex-spec.md` at the project root.

Prior audit rounds against this framework's pristine state returned **0 findings**. The acceptance criterion for that audit class (AC-6b) requires the count be in the range **[10, 35]**. I suspect the prior auditors were too shallow. **Your job is to determine empirically whether the framework is genuinely defect-free at this audit depth — or whether deeper probing surfaces real issues.**

## Your scope

Investigate the APEX framework at the current `HEAD` commit. Focus areas (in priority order):

1. **`framework/hooks/`** (60+ hook scripts) — read the source of each guard hook. Look for:
   - Silent-failure branches (any `2>/dev/null` swallowing real errors; any `return 0` or `exit 0` on a failure code path)
   - Regex deny patterns that have known bypass classes (case-folding gaps; word-boundary anchors that admit edge cases; Unicode-equivalent confusables)
   - Stateful guards (exfil-guard, sequence-guard) whose state-transition logic has gaps (off-by-one on threshold; race conditions)
   - Hooks declared in `framework/HOOK-CLASSIFICATION.md` whose actual exit-code behavior differs from their declared category (block/flag/log-only)

2. **`framework/agents/`** — agent definition files (executor.md, critic.md, verifier.md, framework-auditor.md, round-checker.md, etc.). Look for:
   - Procedural instructions that lack enforcement (instruction says "MUST X" but no test fixture verifies)
   - Three-place-contract violations (a contract declared in agent.md but missing from settings.json OR from test layer)
   - Audit-trail emission claims that aren't checkable (says "emit event X" but no schema validates X)

3. **`framework/schemas/`** — JSON schemas. Look for:
   - Schema-vs-implementation drift (schema says field X required; implementation emits without X)
   - `additionalProperties: false` violations
   - Missing schemas for emitted event types in `.apex/event-log.jsonl`

4. **`apex-spec.md`** — the binding specification. Look for:
   - Internal contradictions (TOC entry pointing to non-existent body section; principles that contradict each other)
   - "MUST" statements that aren't anchored to any specific file/mechanism
   - Forward-references that should have shipped by now (any "Phase N" deliverable whose phase has passed)

5. **`framework/tests/`** — the test suite itself. Run `bash framework/tests/run-all.sh` and observe. Look for:
   - Failing tests (any failed:>0 in the summary)
   - Tests that PASS but assert nothing meaningful (vacuous tests; `+0` counter patterns; comment-only assertions)
   - Tests missing for spec-named hooks (some guard has no dedicated test file)

## Your procedure (BINDING)

### Phase 1 — Open exploration

Spend at least **15 minutes** of pure read-only investigation. Use Explore agents in parallel if helpful. Do NOT yet decide what's a "real defect" — just GATHER observations.

### Phase 2 — Anchor every observation

For each observation from Phase 1, verify:
- The observation is anchored to a SPECIFIC file + line number
- The observation contradicts a SPECIFIC apex-spec.md anchor OR an internal cross-reference
- The observation is REPRODUCIBLE by an independent reader

If you can't anchor it, drop it. Anti-fabrication discipline is mandatory.

### Phase 3 — Classify severity

For each anchored observation, assign:
- **P0** — Spec-mandated mechanism missing or broken; affects a P0/P1 IMP in apex-spec.md
- **P1** — Spec-mandated mechanism degraded; affects P1/P2 IMP
- **P2** — Cross-contract drift between two artifacts (schema↔impl, doc↔code, etc.)
- **P3** — Documentation gap or forward-reference inconsistency

### Phase 4 — Output a structured plan document

Per Plan Mode protocol: write your findings to the plan file the harness specifies. Structure: