mapify-cli 3.35.0__tar.gz → 3.35.2__tar.gz

{mapify_cli-3.35.0 → mapify_cli-3.35.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: mapify-cli
-Version: 3.35.0
+Version: 3.35.2
 Summary: MAP Framework installer - Modular Agentic Planner for Claude Code
 Project-URL: Homepage, https://github.com/azalio/map-framework
 Project-URL: Repository, https://github.com/azalio/map-framework.git
@@ -26,6 +26,7 @@ Requires-Dist: pytest-asyncio>=0.26.0; extra == 'dev'
 Requires-Dist: pytest-cov>=4.0.0; extra == 'dev'
 Requires-Dist: pytest-mock>=3.10.0; extra == 'dev'
 Requires-Dist: pytest-timeout>=2.1.0; extra == 'dev'
+Requires-Dist: pytest-xdist>=3.5.0; extra == 'dev'
 Requires-Dist: pytest>=7.0.0; extra == 'dev'
 Requires-Dist: pyyaml>=6.0.0; extra == 'dev'
 Requires-Dist: ruff>=0.1.0; extra == 'dev'
@@ -39,6 +40,7 @@ Requires-Dist: pytest-asyncio>=0.26.0; extra == 'test'
 Requires-Dist: pytest-cov>=4.0.0; extra == 'test'
 Requires-Dist: pytest-mock>=3.10.0; extra == 'test'
 Requires-Dist: pytest-timeout>=2.1.0; extra == 'test'
+Requires-Dist: pytest-xdist>=3.5.0; extra == 'test'
 Requires-Dist: pytest>=7.0.0; extra == 'test'
 Requires-Dist: pyyaml>=6.0.0; extra == 'test'
 Description-Content-Type: text/markdown
@@ -236,7 +238,7 @@ The DevOpsConf 2026 case study applies this process to a production Kubernetes P
 
 For stacked PRs, use `/map-review --base-ref runtime` (Codex: `$map-review --base-ref runtime`) to review only the child branch's changes against its parent's merge-base, including dirty work. Trusted review policy still comes from the default branch.
 
-Large `/map-review` bundles are delivered in bounded portions by the parent to the same reviewer. The full admitted evidence remains available within the 512 KiB message limit, including for Codex reviewers without shell or MCP access; missing or stale context keeps the review incomplete. Durable delivery acknowledgments and a post-delivery finalization token prevent premature final captures.
+`/map-review` requires coverage of changed paths against the selected base, including local edits. Unchanged repository files remain optional, snapshot-bound dependency context. Codex `$map-review` uses a runner-owned app-server connection to deliver evidence directly to independent readers; the parent no longer copies every chunk. Interrupted collection resumes its saved threads and offsets. Runtime host probes, intact delivery acknowledgments and post-delivery finalization tokens are required before a Codex review can complete; the legacy native reader remains unverified.
 
 [Detailed usage and options →](docs/USAGE.md)
 

{mapify_cli-3.35.0 → mapify_cli-3.35.2}/README.md

@@ -191,7 +191,7 @@ The DevOpsConf 2026 case study applies this process to a production Kubernetes P
 
 For stacked PRs, use `/map-review --base-ref runtime` (Codex: `$map-review --base-ref runtime`) to review only the child branch's changes against its parent's merge-base, including dirty work. Trusted review policy still comes from the default branch.
 
-Large `/map-review` bundles are delivered in bounded portions by the parent to the same reviewer. The full admitted evidence remains available within the 512 KiB message limit, including for Codex reviewers without shell or MCP access; missing or stale context keeps the review incomplete. Durable delivery acknowledgments and a post-delivery finalization token prevent premature final captures.
+`/map-review` requires coverage of changed paths against the selected base, including local edits. Unchanged repository files remain optional, snapshot-bound dependency context. Codex `$map-review` uses a runner-owned app-server connection to deliver evidence directly to independent readers; the parent no longer copies every chunk. Interrupted collection resumes its saved threads and offsets. Runtime host probes, intact delivery acknowledgments and post-delivery finalization tokens are required before a Codex review can complete; the legacy native reader remains unverified.
 
 [Detailed usage and options →](docs/USAGE.md)
 

{mapify_cli-3.35.0 → mapify_cli-3.35.2}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "mapify-cli"
-version = "3.35.0"
+version = "3.35.2"
 description = "MAP Framework installer - Modular Agentic Planner for Claude Code"
 authors = [{ name = "MAP Framework Contributors" }]
 readme = "README.md"
@@ -29,6 +29,7 @@ test = [
     "pytest-cov>=4.0.0",
     "pytest-mock>=3.10.0",
     "pytest-timeout>=2.1.0",
+    "pytest-xdist>=3.5.0",
     "pyyaml>=6.0.0",
     "hypothesis>=6.0.0",
     "jsonschema>=4.0.0",
@@ -39,6 +40,7 @@ dev = [
     "pytest-cov>=4.0.0",
     "pytest-mock>=3.10.0",
     "pytest-timeout>=2.1.0",
+    "pytest-xdist>=3.5.0",
     "pyyaml>=6.0.0",
     "hypothesis>=6.0.0",
     "jsonschema>=4.0.0",
@@ -114,6 +116,8 @@ exclude = [
 # that otherwise ignores .venv and spuriously reports unresolved imports).
 venvPath = "."
 venv = ".venv"
+# Installed runtime scripts import their siblings when invoked directly.
+extraPaths = ["src/mapify_cli/templates/map/scripts"]
 exclude = [
     "**/node_modules",
     "**/__pycache__",

{mapify_cli-3.35.0 → mapify_cli-3.35.2}/src/mapify_cli/__init__.py

@@ -23,7 +23,7 @@ Or install globally:
     mapify check
 """
 
-__version__ = "3.35.0"
+__version__ = "3.35.2"
 
 # MUST stay the first import: it turns "this interpreter is older than 3.11" into
 # a message that says so, instead of the ImportError raised by `from datetime

{mapify_cli-3.35.0 → mapify_cli-3.35.2}/src/mapify_cli/schemas.py

@@ -1426,6 +1426,14 @@ REVIEW_BUNDLE_SCHEMA = {
                 "files": {"type": "array", "items": {"type": "object"}},
             }, "required": ["status", "files"], "additionalProperties": True,
         },
+        "context_artifacts": {
+            "type": "object", "additionalProperties": {
+                "type": "array", "items": {
+                    "type": "object", "properties": {"path": {"type": "string"}, "content": {"type": "string"}},
+                    "required": ["path", "content"], "additionalProperties": False,
+                },
+            },
+        },
         "generated_at": {"type": "string"},
         "artifacts": {
             "type": "object",

{mapify_cli-3.35.0 → mapify_cli-3.35.2}/src/mapify_cli/templates/codex/agents/review-reader.toml

@@ -3,6 +3,9 @@ description = "Shell-free MAP reviewer using runner-supplied source evidence"
 sandbox_mode = "read-only"
 
 developer_instructions = """
+Dispatch status: optional legacy native reader; unverified and unable to approve.
+The supported /map-review path uses codex_review_runner.py environment-free threads.
+
 You are an independent reviewer, never an executor or editor. Follow the role,
 quality rubric, evidence requirements and output schema in the generated prompt
 exactly: Monitor correctness/security/testing, Predictor integration/reachability,

{mapify_cli-3.35.0 → mapify_cli-3.35.2}/src/mapify_cli/templates/codex/skills/map-auto/SKILL.md

@@ -72,7 +72,7 @@ python3 .map/scripts/map_step_runner.py record_auto_phase "<phase>" "<status>" \
   --reason "<why this status>"
 ```
 
-`<phase>` is the workflow name being entered/exited (`map-plan`, `map-efficient`, `map-check`, or `map-review`). `<status>` follows the phase's own vocabulary -- use `completed` on a clean phase close and `aborted`/`failed` on a phase you cannot recover; anything else leaves the chain `in_progress`. Pass every hold id that `auto_decide_holds` auto-approved for this phase in `--evidence-refs`, so the approval is recorded twice: once in the hold's own audit note, once in the phase ledger.
+`<phase>` is the workflow name being entered/exited (`map-plan`, `map-efficient`, `map-check`, or `map-review`). `<status>` follows the phase's own vocabulary -- use `completed` on a clean phase close and `aborted`/`failed` on a phase you cannot recover; anything else leaves the chain `in_progress`. Phase completion and route completion are separate: a `completed` phase closes the chain only when it is the last phase of the selected route -- `map-review` for the multi-phase `map-plan` and `map-efficient` routes, or the route's only phase for the single-phase `map-resume`, `map-check`, and `map-fast` routes. Any earlier `completed` leaves the chain `in_progress` so the next phase is accepted. Pass every hold id that `auto_decide_holds` auto-approved for this phase in `--evidence-refs`, so the approval is recorded twice: once in the hold's own audit note, once in the phase ledger.
 
 **At most one re-entry per phase (HC-2):** `record_auto_phase` mechanically enforces this -- the first record of a phase name is `attempt: 1`, a re-entry is `attempt: 2`, and a third call for the SAME phase name is refused and force-aborts the chain (`chain_status: "aborted"`). Before spending the single permitted re-entry, inspect ground truth -- `git status`/`git diff` and the phase's own `step_state.json` (or equivalent phase artifacts, test output, Monitor verdict) -- to confirm the phase genuinely needs a fresh attempt rather than a partial success being misread as a failure. A second failure of the same phase means STOP and hand off to `$map-resume` -- never attempt a third call for that phase. A chain already `chain_status: "aborted"` or `"blocked"` refuses every further `record_auto_phase` call regardless of phase name; a new `route_task` call is the ONLY legitimate way to continue.
 
@@ -84,8 +84,8 @@ Once routed, drive the selected chain by invoking the existing slash workflows e
 route_task -> [map-plan] -> [map-efficient] -> [map-check] -> [map-review]
 ```
 
-- `map-resume`, `map-check`, and `map-fast` routes are single-phase: run the one workflow, record its result with `record_auto_phase`, and finish.
-- `map-plan` and `map-efficient` routes continue the chain: `map-plan` produces the task plan that `map-efficient` consumes, `map-efficient` implements it, and the chain then continues to `map-check` and `map-review` to close the loop.
+- `map-resume`, `map-check`, and `map-fast` routes are single-phase: run the one workflow, record its result with `record_auto_phase`, and finish -- the route's only phase closes the chain.
+- `map-plan` and `map-efficient` routes continue the chain: `map-plan` produces the task plan that `map-efficient` consumes, `map-efficient` implements it, and the chain then continues to `map-check` and `map-review` to close the loop. The route stays `chain_status: in_progress` after each intermediate phase completes and closes only when `map-review` completes.
 - Invoke each phase by reading and following its own `SKILL.md` in full, exactly as if the user had typed the corresponding slash command -- do not summarize, skip, or reimplement its internal steps. `$map-auto` never shells out to a separate Claude process, a new Python execution engine, or any other new phase-driving mechanism to do this -- phases are driven ONLY by invoking the existing slash workflows above and the three runner subcommands from Steps 1-3.
 - A `valid=false` Monitor verdict INSIDE a phase is that phase's own hard stop: its owning workflow's existing retry/escalation rules apply unchanged. `$map-auto` never overrides, suppresses, or re-runs past a Monitor rejection on the phase's behalf -- a phase that cannot get past Monitor is a failed phase for the purposes of Step 3's re-entry bound.
 - The autopilot run ends at a committed feature branch. `$map-auto` never opens a pull request, never merges, and never polls CI -- report the committed branch, the phases recorded, and stop.

{mapify_cli-3.35.0 → mapify_cli-3.35.2}/src/mapify_cli/templates/codex/skills/map-auto/auto-reference.md

@@ -15,7 +15,7 @@ python3 .map/scripts/map_step_runner.py record_auto_phase <phase> <status> [--br
 
 - `route_task <task>` -- `<task>` is the free-text task description (quote it). `--branch` defaults to the current branch. `--dry-run` recommends a route without marking the chain `in_progress` (see Dry-run usage below).
 - `auto_decide_holds` -- no positional arguments; only `--branch` (defaults to current branch).
-- `record_auto_phase <phase> <status>` -- `<phase>` is the workflow name (`map-plan`, `map-efficient`, `map-check`, `map-review`); `<status>` is the phase's own outcome word (`completed`, `failed`, `aborted`, or any other phase-specific status, which leaves `chain_status` at `in_progress`). `--evidence-refs` takes a comma-separated list of ids (auto-approved hold ids from the surrounding `auto_decide_holds` calls); `--reason` is a free-text note stored on the ledger entry.
+- `record_auto_phase <phase> <status>` -- `<phase>` is the workflow name (`map-plan`, `map-efficient`, `map-check`, `map-review`); `<status>` is the phase's own outcome word (`completed`, `failed`, `aborted`, or any other phase-specific status, which leaves `chain_status` at `in_progress`). A `completed` status closes the chain (`chain_status: "completed"`) only on the LAST phase of the selected route -- `map-review` for multi-phase `map-plan`/`map-efficient` routes, or the single phase of `map-resume`/`map-check`/`map-fast`; a `completed` intermediate phase keeps the chain `in_progress`. `--evidence-refs` takes a comma-separated list of ids (auto-approved hold ids from the surrounding `auto_decide_holds` calls); `--reason` is a free-text note stored on the ledger entry.
 
 ## Chain Walkthrough Example
 
@@ -35,10 +35,12 @@ $ python3 .map/scripts/map_step_runner.py auto_decide_holds
 
 $ python3 .map/scripts/map_step_runner.py record_auto_phase "map-efficient" "completed" \
   --evidence-refs "hold-1" --reason "all subtasks closed, make check green"
-{"status": "success", "chain_status": "completed", "phase": "map-efficient", "attempt": 1, ...}
+{"status": "success", "chain_status": "in_progress", "phase": "map-efficient", "attempt": 1, ...}
 
-# -- chain then continues to map-check, then map-review, each following the same
-#    poll -> drive -> poll -> record loop, until the last phase records "completed" --
+# -- map-efficient is not the last phase of this route: the chain stays
+#    in_progress and continues to map-check, then map-review, each following the
+#    same poll -> drive -> poll -> record loop. Only map-review completing closes
+#    the route (chain_status: "completed") --
 ```
 
 The run ends there: a committed feature branch, `phases[]` in `auto-route.json` holding one entry per phase attempt, and no PR/merge/CI step of any kind.

{mapify_cli-3.35.0 → mapify_cli-3.35.2}/src/mapify_cli/templates/codex/skills/map-release/SKILL.md

@@ -71,7 +71,7 @@ Execute all 12 gates. Read the full gate scripts in [release-reference.md § Pha
 **Gate summary (full commands in reference):**
 - **Gates 1–4:** `make check` — tests, ruff, mypy, pyright, rendered-template parity
 - **Gates 5–6:** Build + twine check
-- **Gate 7:** Security audit (`pip-audit`)
+- **Gate 7:** Security audit of the project's resolved requirements (`uv export` + `pip-audit -r`)
 - **Gates 8–10:** Git state — main branch, clean working directory, up-to-date with origin
 - **Gate 11:** CI run for `git merge-base HEAD origin/main` must have `conclusion: "success"`; unpushed commits may touch only release metadata
 - **Gate 12:** CHANGELOG.md completeness (Unreleased section exists and has content; commit/entry gap check)

{mapify_cli-3.35.0 → mapify_cli-3.35.2}/src/mapify_cli/templates/codex/skills/map-release/release-reference.md

@@ -35,11 +35,20 @@ uv run --with twine twine check dist/*
 ### Gate 7: Security Audit
 
 ```bash
-pip install pip-audit
-pip-audit
+set -euo pipefail
+# Audit the project's resolved dependency set, not the runner interpreter.
+REQS_FILE=$(mktemp "${TMPDIR:-/tmp}/mapify-release-reqs.XXXXXX")
+trap 'rm -f "$REQS_FILE"' EXIT
+uv export --all-extras --all-groups --no-hashes --no-emit-project \
+  --format requirements-txt > "$REQS_FILE"
+# --no-deps audits exactly the exported pins; --disable-pip stops pip from
+# resolving or mutating the runner environment.
+uvx pip-audit -r "$REQS_FILE" --disable-pip --no-deps
 ```
 
 **Expected Results:**
+- ✅ `uv export` resolves the project's dependencies (all extras and groups)
+- ✅ `pip-audit` audits the exported pinned requirements, not the runner environment
 - ✅ No known security vulnerabilities in dependencies
 
 **If vulnerabilities found:** Assess severity; update dependencies if critical.

{mapify_cli-3.35.0 → mapify_cli-3.35.2}/src/mapify_cli/templates/codex/skills/map-review/SKILL.md

@@ -25,7 +25,7 @@ parallel_tool_policy: single_review_fanout
 ```
 
 - Use deeper reasoning for verdicts, risk ranking, section tradeoffs, and contradictory reviewer evidence.
-- Use exactly one parallel reviewer fan-out after bundle preparation: Monitor, Predictor, Evaluator, the two role reviewers, and the optional complexity lens may run together because they inspect the same review input independently.
+- Use one runner invocation after bundle preparation; it collects independent reviewer threads in order and owns recovery. Do not launch an additional native fan-out.
 - Wait for all reviewer agents before section presentation. Do not parallelize interactive decisions, ordering comparisons that share state, or review-bundle writes.
 
 ## Flags
@@ -52,7 +52,9 @@ parallel_tool_policy: single_review_fanout
 7. **Monitor `valid=false` requires verification, not immediate publication** — Step A.3 verifies evidence and bug-introduced-here BEFORE Phase B. Bare claims become `needs_investigation`, not published issues.
 8. Present options neutrally as A/B/C. Append `(Recommended)` after the option label, not by position.
 
-**Codex — supported review states:** run `$map-review` (normal, `--adversarial`, `--cross-ai`) with no `.map/<branch>/step_state.json`, in `COMPLETE`/`WORKFLOW_COMPLETE`, or in `MONITOR` while `MAP_MONITOR_HOTFIX` is not `0`. In other non-editing phases (e.g. `DECOMPOSE`, `PREDICTOR`, or `MONITOR` with `MAP_MONITOR_HOTFIX=0`) the Codex workflow-gate hook denies shell writes to `$`-expanded targets (precheck log, `review-mode.json`, reviewer envelopes, adversarial files). On such a deny, archive the stale workflow (or finish it) or rerun `$map-review` from a supported state — do not work around the hook.
+**Codex collection:** the supported driver owns captures and continuation; the skill
+has no shell-expanded capture targets. Normal workflow-state and snapshot gates
+remain authoritative. Do not bypass a host or workflow denial.
 
 ## Review Preferences (Customize per project)
 
@@ -337,129 +339,47 @@ if [ "$DETACHED_FLAG" = "true" ]; then
 fi
 ```
 
-If `DETACHED_STATUS` is `success`, tell reviewer agents to read source files from `$DETACHED_PATH` read-only. If status is `unavailable` or `error`, announce `$DETACHED_REASON` and continue in place. Do not mutate the source branch.
+If `DETACHED_STATUS` is `success`, retain the detached tree for operator inspection; the driver still serves only the admitted immutable resources. If status is `unavailable` or `error`, announce `$DETACHED_REASON` and continue in place. Do not mutate the source branch.
 
 ### Step A.1d: Prepare compare-mode ordering (optional, `--compare-orderings` only)
 
 When compare mode is active, run two review collections with `ordering_label='default'` and `ordering_label='reverse'`, then call `compare-review-runs` and `record-review-ordering` to stage the drift summary. See [review-reference.md](review-reference.md#compare-orderings) for the detailed loop.
 
-On Codex, `<n>` in `task_name` (the `map_review_<role>_<n>` counter from Step A.2) keeps incrementing across both collections, so the second (`reverse`) collection dispatches with fresh names.
+On Codex, one driver invocation collects both orderings with separate persisted native threads. Rerunning it resumes unfinished threads and reuses intact completed captures.
 
-### Step A.2: Launch all parallel calls
-Before launching agents, build the reviewer prompts with `build_review_prompts`. Evidence is NOT truncated. The admitted immutable bundle backs a compact initial prompt and parent-served resources; large original prompts, full file inventory and permitted base/current sources arrive in chunks through Step A.2a. `MAP_REVIEW_PROMPT_BUDGET_TOKENS` is informational and clips nothing. The 512 KiB limit still applies to each initial prompt and serialized context response. On a builder error, stop dispatch and report the reason; never bypass admission or remove evidence to fit.
+### Step A.2: Collect reviewer reports
 
-```bash
-REVIEW_PROMPTS_JSON=$(python3 .map/scripts/map_step_runner.py build_review_prompts \
-  --review-preferences "[paste Review Preferences section above]")
-printf '%s' "$REVIEW_PROMPTS_JSON" | python3 -c 'import json,sys; d=json.load(sys.stdin); sys.exit(0 if d.get("status") == "success" else json.dumps(d, indent=2))' || exit 1
-MONITOR_PROMPT=$(printf '%s' "$REVIEW_PROMPTS_JSON" | python3 -c 'import json,sys; print(json.load(sys.stdin)["prompts"]["monitor"]["prompt"])')
-PREDICTOR_PROMPT=$(printf '%s' "$REVIEW_PROMPTS_JSON" | python3 -c 'import json,sys; print(json.load(sys.stdin)["prompts"]["predictor"]["prompt"])')
-EVALUATOR_PROMPT=$(printf '%s' "$REVIEW_PROMPTS_JSON" | python3 -c 'import json,sys; print(json.load(sys.stdin)["prompts"]["evaluator"]["prompt"])')
-COMPLEXITY_LENS_PROMPT=$(printf '%s' "$REVIEW_PROMPTS_JSON" | python3 -c 'import json,sys; data=json.load(sys.stdin); print(data.get("prompts",{}).get("complexity_lens",{}).get("prompt", ""))')
-COMPLEXITY_LENS_ENABLED=$(printf '%s' "$REVIEW_PROMPTS_JSON" | python3 -c 'import json,sys; data=json.load(sys.stdin); print("true" if data.get("prompts",{}).get("complexity_lens") else "false")')
-USER_EXPERIENCE_PROMPT=$(printf '%s' "$REVIEW_PROMPTS_JSON" | python3 -c 'import json,sys; print(json.load(sys.stdin)["prompts"]["user_experience"]["prompt"])')
-SECURITY_PROMPT=$(printf '%s' "$REVIEW_PROMPTS_JSON" | python3 -c 'import json,sys; print(json.load(sys.stdin).get("prompts", {}).get("security", {}).get("prompt", ""))')
-MAINTAINER_PROMPT=$(printf '%s' "$REVIEW_PROMPTS_JSON" | python3 -c 'import json,sys; print(json.load(sys.stdin)["prompts"]["maintainer"]["prompt"])')
-```
-
-Use the extracted prompt variables as the spawn_agent messages. Keep reviewer spawn calls below the bundle and prompt-builder commands.
-
-```text
-spawn_agent(agent_type="review-reader", task_name="map_review_monitor_<n>", message=MONITOR_PROMPT)
-spawn_agent(agent_type="review-reader", task_name="map_review_predictor_<n>", message=PREDICTOR_PROMPT)
-spawn_agent(agent_type="review-reader", task_name="map_review_evaluator_<n>", message=EVALUATOR_PROMPT)
-spawn_agent(agent_type="review-reader", task_name="map_review_user_experience_<n>", message=USER_EXPERIENCE_PROMPT)
-spawn_agent(agent_type="review-reader", task_name="map_review_maintainer_<n>", message=MAINTAINER_PROMPT)
-If security is in admitted roster: spawn_agent(agent_type="review-reader", task_name="map_review_security_<n>", message=SECURITY_PROMPT)
-If COMPLEXITY_LENS_ENABLED=true: spawn_agent(agent_type="review-reader", task_name="map_review_complexity_lens_<n>", message=COMPLEXITY_LENS_PROMPT)
-```
-
-Codex dispatch rules:
-
-- `<n>` increments on every dispatch in the run (including the Step A.2b truncation retry and the second `--compare-orderings` collection), so every call gets a unique `task_name`.
-- Each call sends its generated prompt as `message`, plus a reminder that the reviewer is read-only and may return intermediate `context_request` JSON before its required final output.
-- Wait for all dispatched reviewers and map each final JSON back to its role variable (`MONITOR_OUTPUT`, `PREDICTOR_OUTPUT`, `EVALUATOR_OUTPUT`, `USER_EXPERIENCE_OUTPUT`, `MAINTAINER_OUTPUT`, `SECURITY_OUTPUT`, and `COMPLEXITY_LENS_OUTPUT` when enabled).
-- If concurrency is unavailable, make the same calls sequentially.
-- Never replace independent review with parent-session personas.
-- Every reviewer uses `review-reader`; the generated role prompt supplies its complete role protocol, rubric and schema. Do not route through general-purpose or execution-capable profiles.
-- `capability_enforcement=unverified`: shell/delegation disabling settings and read-only sandbox are defense in depth, not runtime proof of no writes/native read-search. Continue review and finding publication from source content in the runner bundle; the result is INCOMPLETE and cannot approve. Never disable the whole Codex review or silently restore shell (#526).
-
-Role reviewers remain isolated; follow the access and attribution rules in [Parent-served context loop](review-reference.md#parent-served-context-loop-step-a2a).
-
-Reviewer prompts reference `review-bundle.json`, `review-bundle.md`, the raw diff as secondary context, and the expected output schema.
-
-When enabled (`minimality != off`), the complexity lens is advisory only. It lists over-engineering as `delete:`, `stdlib:`, `native:`, `yagni:`, or `shrink:` findings, ends with `net: -<N> lines possible.` or `Lean already. Ship.`, samples `map:simplification:` marker claims, and never feeds Actor retries or verdict gates.
-
-### Step A.2a: Deliver requested context to the same reviewer (MANDATORY)
-
-Before final JSON validation, follow [Parent-served context loop](review-reference.md#parent-served-context-loop-step-a2a): run `serve_review_context` for every response, including retries, adversarial roles and the complexity lens. Continue the same agent for `context_response`; responses to the post-delivery finalization request proceed to Step A.2b even with missing or invalid receipts. Discard queued early finals; context requests never consume final-response retries or become captured reviews. Denied/stale context leaves collection incomplete.
-
-### Step A.2b: Truncated-response gate (MANDATORY — post-fan-out, pre-verification)
-
-After Step A.2a identifies a final response, pipe it on stdin (a bare call returns
-`status:"no_input"`, not a pass):
-`printf '%s' "$RESPONSE" | python3 .map/scripts/map_step_runner.py detect_truncated_agent_output --agent <kind>`
-using the role-specific kind shown below. On truncation or missing/invalid finalization `context_receipt`: log via
-`log_agent_failure --agent <role> --phase post-invoke --failure-label truncated --reasons '<reasons>'`
-and re-invoke that reviewer ONCE using the prompt from
-`build_json_retry_prompt --agent <role> --errors '<reasons>'`; if still
-malformed, stop with CLARIFICATION_NEEDED.
-Include the original generated prompt and context protocol with retry instructions; process intermediate requests through Step A.2a.
-
-On Codex, the re-invocation is a new `spawn_agent` call: `<n>` keeps incrementing, so the retry gets a fresh `task_name`.
-
-Role → `--agent` kind for the truncation check:
-- monitor reviewer → `--agent review-monitor` (enforces the full review schema:
-  evidence/valid/summary/verdict/issues/passed_checks/failed_checks)
-- predictor reviewer → `--agent predictor`
-- evaluator reviewer → `--agent evaluator`
-- role reviewers → `--agent user_experience` / `--agent maintainer` / `--agent security`
-
-The optional complexity lens returns plain text, not JSON. Do not run the JSON truncation gate on it; if it is empty or visibly cut off, rerun only that lens prompt once.
-
-### Step A.2c: Capture reviewer envelopes (MANDATORY — the ledger reads these)
-
-Once a reviewer clears the truncation gate, write its JSON envelope verbatim to
-`.map/<branch>/review-agent-<role>.json` (`monitor`, `predictor`, `evaluator`,
-`user_experience`, `maintainer`; include `security` only when it is in the
-admitted roster, plus `adversarial` in adversarial/compare-orderings mode). The verdict ledger is
-computed from these files — a role whose file is missing is recorded as an
-unobserved review, not as a clean one.
+Use the runner-owned Codex app-server transport. Do not launch native review-reader
+subagents or relay context through the main conversation. For adversarial mode,
+use the corresponding command in adversarial-reference.md instead of this section.
 
 ```bash
-BRANCH=$(python3 .map/scripts/map_utils.py branch)
-BRANCH_DIR=".map/$BRANCH"
-# For compare-orderings set ORDERING_LABEL=default or reverse in this call.
-# Preserve both collections; do not call begin_review_run between them.
-if [ -n "${ORDERING_LABEL:-}" ]; then BRANCH_DIR="$BRANCH_DIR/review-collections/$ORDERING_LABEL"; fi
-mkdir -p "$BRANCH_DIR"
-
-REVIEW_ROUND_ID="${REVIEW_ROUND_ID:-$(python3 -c 'import json,sys; print(json.load(open(sys.argv[1]))["round_id"])' ".map/$BRANCH/review-mode.json")}"
-python3 .map/scripts/map_step_runner.py capture_review_output \
-  --reviewer monitor --round-id "$REVIEW_ROUND_ID" --ordering "${ORDERING_LABEL:-}" <<'MONITOR_EOF'
-<paste the Monitor JSON envelope verbatim>
-MONITOR_EOF
+python3 .map/scripts/codex_review_runner.py --review-preferences "[paste Review Preferences section above]"
 ```
 
-The quoted heredoc marker (`<<'MONITOR_EOF'`, quotes included) is what stops the
-shell expanding anything inside the payload. Repeat for `predictor`,
-`evaluator`, `user_experience` and `maintainer`; repeat for `security` only when it is in the admitted roster. In adversarial or
-compare-orderings mode write the complete tagged aggregate to
-`review-agent-adversarial.json` instead, including `ledger_findings`,
-`reviewer_status` and `parse_errors`; an empty findings array alone cannot prove review.
-
-Every reviewer envelope includes
-`receipt={covered_files:[],skipped_files:[],denied_access:[],check_evidence:[check_id]}`.
-Coverage means actual source paths inspected (including supplied source content),
-not acceptance citations; reading claims remain `self_reported`. Check references
-must be current runner-issued IDs, never claimed executions. Preserve each raw
-reviewer receipt in the adversarial aggregate's `reviewer_status[role].raw`;
-a top-level aggregate receipt cannot substitute for individual coverage.
-Reviewers may submit structured `resolved_findings` using the full evidence and
-sibling-remediation contract in review-reference.md § Evidence validation in the admitted round.
-Only the originating reviewer may request closure; free text or omission is not
-resolution. Fresh checked evidence is required, not a tool-witnessed execution claim.
-Preserve file/location/failure-scenario evidence so distinct defects stay distinct.
+Keep this command running and poll its process with the host's normal process tools;
+progress names the current role. A tool timeout is not a completed review. If the
+process was interrupted, rerun the command under the same admitted round and omit
+`--review-preferences`: the exact preferences are saved on first collection, alongside
+native thread IDs, pending chunks and acknowledged offsets. Explicitly different
+preferences are rejected; omission reuses the saved text. A lost
+thread or stale snapshot is an explicit error; never invent ACKs or replace its
+session silently. Do not call begin_review_run for another round to hide a failure.
+
+The driver builds compact role prompts, serves immutable resources through one
+read-only dynamic tool, checks intact Code Mode output before ACK, resizes truncated
+chunks, validates final envelopes and captures them in the usual ledger paths.
+Each role has an independent environment-free Codex thread. A runtime probe checks
+actual tool inventory, successful source delivery and a denied canary write before
+any repository evidence is supplied. COMPLETE requires every admitted reader's
+host witness as well as scope, snapshot/policy, checks and finalization receipts.
+The legacy native profile remains `capability_enforcement=unverified`: findings
+remain publishable, but that route stays INCOMPLETE and cannot approve. A failed
+probe never becomes verified by configuration, version text or model assertion.
+
+Reading claims in `receipt={covered_files:[],skipped_files:[],denied_access:[],check_evidence:[]}`
+remain self_reported. The optional complexity lens stays advisory. On driver success,
+continue at Step A.3 using captured artifacts; do not dispatch a second reviewer set.
 
 ### Step A.3: Verification gate (MANDATORY before any presentation)
 
@@ -531,17 +451,11 @@ When `--adversarial` is set (with `--cross-ai`: present cross-AI first, then thi
 ### Quick reference
 
 ```text
-1. Build prompts:  python3 .map/scripts/map_step_runner.py build_adversarial_review_prompts --reviewers <comma-separated admitted roster>
-2. Fan-out:        spawn_agent(agent_type="review-reader", task_name="map_review_<role>_<n>", message=<ROLE>_PROMPT)
-                   for every role in the admitted roster — parallel, then wait for all (strict overrides --quick)
-3. Validate:       Each must return valid JSON per adversarial finding schema; retry ONCE on failure
-4. Aggregate:      python3 .map/scripts/map_step_runner.py aggregate_adversarial_findings --blind <path> [--edge-case <path> when admitted] --acceptance <path> --user-experience <path> --maintainer <path> [--security <path> when admitted]
-5. Present:        Unified report: CRITICAL/IMPORTANT/MINOR, convergence section, all-clear statements (--show-raw-findings for debug)
-6. Feed ledger:    persist the complete tagged aggregate to "$BRANCH_DIR/review-agent-adversarial.json"
-                   including ledger_findings, reviewer_status and parse_errors
-7. Skip to:        Final Verdict → Handoff Artifacts; do NOT run normal 4-section walkthrough
-                   The verdict is computed by the ledger from those findings — this phase
-                   does not assign one.
+1. Collect: python3 .map/scripts/codex_review_runner.py
+            Builds prompts, validates reports and captures the aggregate for the admitted roster.
+            On interruption rerun the same command in the same admitted round.
+2. Present: Read the captured aggregate; show findings, convergence and all-clear statements.
+3. Continue: Final Verdict → Handoff Artifacts. The ledger computes the verdict.
 ```
 
 ## Phase B: Interactive Presentation (4 Sections) — NORMAL MODE ONLY

mapify_cli-3.35.2/src/mapify_cli/templates/codex/skills/map-review/adversarial-reference.md

@@ -0,0 +1,110 @@
+# Adversarial Review Reference
+
+Detailed workflow for `map-review --adversarial`. See [SKILL.md](SKILL.md) for context and integration points.
+
+## Overview
+
+Five reviewers run in parallel, each with only its permitted inputs:
+
+| Reviewer | Context | Finds |
+|----------|---------|-------|
+| **Blind Hunter** | diff only | Typos, dead code, logic errors visible in isolation |
+| **Edge Case Hunter** | diff + repo read access | Null handling, boundary conditions, error paths, codebase consistency |
+| **Acceptance Auditor** | diff + spec + plan + artifacts | Missed requirements, spec violations, AC gaps, extra/unplanned work |
+| **User (`user_experience`)** | diff + repo read access | Regressions in the already-shipped path: extra mandatory steps, confusable flags, an explicit value silently overridden |
+| **Maintainer (`maintainer`)** | diff + repo read access | Branch-scoped litter in comments, implementation leaking into user-facing text, undiagnosable errors, copy-paste, split sources of truth, version predicates by number, embedded foreign-language code, settings carried through layers that only pass them on, names that promise more than the body does, mechanisms named after their first application, files placed against the local convention |
+
+With `--quick`: skip Edge Case Hunter (Blind + Acceptance + both roles).
+
+The two role reviewers answer to the five-part output contract (`problem`,
+`current_code`, `proposed_code`, `why_better`, `cost`). A finding that cannot
+fill all five is dropped by `aggregate_adversarial_findings` into
+`contract_incomplete` — reported, never counted.
+
+## Steps B.adversarial.0–3: Collect through the Codex runner
+
+After admission and immutable bundle creation, run:
+
+```bash
+python3 .map/scripts/codex_review_runner.py
+```
+
+The driver reads the admitted roster, creates independent environment-free threads,
+probes each host boundary, serves only each role's permitted immutable context,
+validates individual reports and captures the tagged adversarial aggregate. Blind
+remains diff-only. Compare-orderings uses separate thread/session/receipt sets.
+Poll the running command; on interruption rerun it under the same admitted round.
+Do not spawn native readers, copy chunks through the parent, or promote an unverified
+probe. See SKILL.md Step A.2 for the capability and recovery contract. Read the
+captured `review-agent-adversarial.json` (or both review-collections in compare mode)
+for presentation, then proceed below.
+
+## Step B.adversarial.4: Present unified adversarial report
+
+Parse the aggregated JSON and present the report in this structure:
+
+```
+# Adversarial Review Report
+
+## Summary
+- Total findings: N (C CRITICAL, I IMPORTANT, M MINOR)
+- Corroborated (found by 2+ reviewers): K — highest confidence
+- Per-reviewer: Blind: B, Edge Case: E, Acceptance: A, User: U, Maintainer: M
+- All-clear: [reviewers who reported all_clear=true]
+- Dropped for an incomplete output contract: [contract_incomplete entries]
+
+## CRITICAL
+[per finding: severity, category, file:line, failure_mode, evidence, reported_by, corroborated flag]
+
+## IMPORTANT
+[per finding: same structure]
+
+## MINOR
+[per finding: same structure]
+
+## Cross-Reviewer Convergence
+[Highlight what multiple reviewers independently found — these are highest-confidence issues]
+
+## Reviewer All-Clear Statements
+[Per reviewer who said all_clear: what they checked and why it's clean]
+```
+
+When `--show-raw-findings` is set, also show the raw per-reviewer JSON files.
+
+## Step B.adversarial.5: Feed the verdict ledger
+
+This phase does not assign a verdict. The capture block persists the complete
+`adversarial_aggregate.v1` report, including `ledger_findings`, `reviewer_status`
+and `parse_errors`. Closeout reads the current roster from `review-mode.json`;
+`write_review_verdict_ledger --current-run` then computes
+`PROCEED`/`REVISE`/`BLOCK` from the decision table in
+[review-reference.md § Verdict Ledger](review-reference.md#verdict-ledger).
+Corroboration raises confidence in the report; it does not change the verdict.
+
+## Step B.adversarial.6: Skip to Final Verdict
+
+After presenting the adversarial report, skip the normal 4-section interactive walkthrough and go directly to Final Verdict → Handoff Artifacts.
+
+## Flow summary for adversarial
+
+When `ADVERSARIAL_FLAG=true`, the workflow is:
+Phase A (all steps) → Phase B: Adversarial Review → Final Verdict → Handoff Artifacts.
+Do NOT run the normal Monitor/Predictor/Evaluator fan-out or the 4-section walkthrough.
+
+## Examples
+
+See [review-reference.md](review-reference.md#examples) for adversarial examples.
+
+## Troubleshooting
+
+### Reviewer returns invalid JSON
+
+Re-invoke that specific reviewer ONCE. If still invalid, record `parse_error` and continue — two valid reviewers are better than zero.
+
+### All reviewers fail
+
+Stop with CLARIFICATION_NEEDED. The diff may be too large or the context too complex for adversarial review.
+
+### Edge Case Hunter runs out of context
+
+Edge Case Hunter has repo read access. If the repo is very large, limit its scope by pre-computing an impact graph of files importing/imported-by the changes plus relevant tests. Defer full implementation to v2.

{mapify_cli-3.35.0 → mapify_cli-3.35.2}/src/mapify_cli/templates/codex/skills/map-review/review-reference.md

@@ -6,7 +6,7 @@ This file contains lower-frequency review details. Keep `SKILL.md` focused on th
 
 New gates default to shadow diagnostics: no new blockers, no reduced existing safeguards. Strict opt-in is `review: {security_gates: strict}` in `.map/config.yaml` on the pinned trusted default branch, never PR-head/local config. In strict mode admission overrides quick/lightweight or reduced explicit rosters for sensitive/unknown changes. Dispatch every admitted reviewer, including the independent `security` role, and capture its own envelope for each ordering. Normal approval and execution checks cannot replace security coverage.
 
-Human consent is a separate snapshot/policy/action-bound `review_consent` hold in the existing durable store. Verified human provenance is currently unavailable: host UI answers, transcripts and caller JSON do not establish it. Never call `decide_approval_hold` to discharge review consent, or reinterpret auto mode, agent votes or successful checks as consent. Report the pending hold in both modes. In strict mode stop before review-ready; do not burn additional review rounds waiting. The strict ready gate remains blocked even when legacy ledger enforcement is disabled. Shadow holds do not add blockers and must never be reported as consent. Positive human ingress remains incomplete under #523; Codex capability remains unverified under #526.
+Human consent is a separate snapshot/policy/action-bound `review_consent` hold in the existing durable store. Verified human provenance is currently unavailable: host UI answers, transcripts and caller JSON do not establish it. Never call `decide_approval_hold` to discharge review consent, or reinterpret auto mode, agent votes or successful checks as consent. Report the pending hold in both modes. In strict mode stop before review-ready; do not burn additional review rounds waiting. The strict ready gate remains blocked even when legacy ledger enforcement is disabled. Shadow holds do not add blockers and must never be reported as consent. Positive human ingress remains incomplete under #523; Legacy native Codex capability remains unverified under #526; the runner-owned app-server path requires per-reader host probes.
 
 Shadow consent-store errors are reported in admission output and persisted in the review ledger when writable; they do not deny admission or ready. Never reset a corrupt hold store: existing generic hold blockers remain enforced. Strict consent-store errors still fail closed. Gate configuration is read from the pinned trusted revision independently of `REVIEW.md` content validation; invalid root/area policy cannot downgrade a strict configuration.
 
@@ -17,8 +17,21 @@ Shadow consent-store errors are reported in admission output and persisted in th
 - Tests: changed behavior, failure cases, fixtures, coverage of acceptance tags.
 - Performance: hot paths, large artifacts, prompt budgets, avoid speculative micro-optimizations.
 
+## Review Scope
+
+Required coverage is the admitted `required_files`: changed paths against the selected base,
+including staged/unstaged/untracked inputs, deletions and both rename sides. The full
+`context_files` inventory remains snapshot-bound and available for dependency checks.
+Unread or explicitly skipped optional context does not make review incomplete.
+
 ## Compare Orderings
 
+For supported Codex reviews, `codex_review_runner.py` performs binding, delivery,
+ACK, finalization and capture, including both compare orderings. Do not perform
+these steps manually. The manual collection instructions below apply only to
+Claude and the legacy unverified native-reader path. Keep the comparison/report
+steps after the driver completes.
+
 When `--compare-orderings` is set, begin the invocation once, then collect with
 `ORDERING_LABEL=default` and `ORDERING_LABEL=reverse` set in each capture call.
 Keep envelopes in `review-collections/default/` and `review-collections/reverse/`;
@@ -238,6 +251,12 @@ decision table (`review_verdict_table.v1`) and writes:
 
 ### Parent-served context loop (Step A.2a)
 
+For supported Codex reviews, `codex_review_runner.py` performs binding, delivery,
+ACK, finalization and capture, including both compare orderings. Do not perform
+these steps manually. The manual collection instructions below apply only to
+Claude and the legacy unverified native-reader path. Keep the comparison/report
+steps after the driver completes.
+
 The role reviewers run in the SAME fan-out but with isolated context: they see
 the diff and the bundle, never the other reviewers' output. They inspect supplied
 base/current source and changed-hunk attribution — the user role checks the old
@@ -278,7 +297,8 @@ retries, both ordering collections and the advisory complexity lens:
    For an early final response, retain no final capture: create the same request
    shape from the status's next `remaining` resource/offset and continue delivery.
    Required resources include the manifest, full original prompt (unless initially
-   inline), inventory and every permitted source resource. Blind stays diff-only.
+   inline), inventory and source resources marked `required`. Unchanged sources
+   are optional dependency context; fetch them only when needed. Blind stays diff-only.
 2. Store the exact returned chunk JSON in a session-specific pending file under
    `.map/<branch>/review-context-delivery/<session-id>/`, then pass that JSON
    verbatim to the **same agent**: