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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: mapify-cli
-Version: 3.35.1
+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

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

@@ -1,6 +1,6 @@
 [project]
 name = "mapify-cli"
-version = "3.35.1"
+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",

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

@@ -23,7 +23,7 @@ Or install globally:
     mapify check
 """
 
-__version__ = "3.35.1"
+__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.1 → 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.1 → 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.1 → 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.1 → 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.1 → mapify_cli-3.35.2}/src/mapify_cli/templates/map/scripts/map_step_runner.py

@@ -20216,20 +20216,51 @@ _AUTO_ROUTE_NEXT_COMMAND: dict[str, str] = {
 
 # /map-auto phase ledger (issue #414): closed status vocabulary for
 # record_auto_phase's chain_status transitions. A phase status in
-# AUTO_PHASE_TERMINAL_SUCCESS_STATUSES completes the chain; a status in
-# AUTO_PHASE_ABORT_STATUSES aborts it; any other status leaves the chain
-# in_progress. These two sets are intentionally NOT required to partition
-# every possible status string -- callers may pass phase-specific statuses
-# (e.g. "monitor_rejected") that fall through to in_progress.
+# AUTO_PHASE_TERMINAL_SUCCESS_STATUSES completes the ROUTE only when that
+# phase is the last phase of the routed chain (see AUTO_ROUTE_PHASE_CHAINS); a
+# status in AUTO_PHASE_ABORT_STATUSES aborts the chain; any other status
+# leaves the chain in_progress. These two sets are intentionally NOT required
+# to partition every possible status string -- callers may pass phase-specific
+# statuses (e.g. "monitor_rejected") that fall through to in_progress.
 AUTO_PHASE_TERMINAL_SUCCESS_STATUSES = frozenset({"completed"})
 AUTO_PHASE_ABORT_STATUSES = frozenset({"aborted", "failed"})
 
+# /map-auto routed phase chains (issue #621): phase completion and route
+# completion are separate. A route reaches chain_status="completed" only when
+# the completed phase is the LAST phase of the chain its selected_route drives.
+# map-resume, map-check and map-fast are single-phase routes; map-plan and
+# map-efficient are multi-phase routes that continue through map-check and
+# close on map-review. Keeping the table beside the terminal-status vocabulary
+# makes the route/phase split explicit instead of inferring "completed" from
+# the phase status alone (the #446 regression).
+AUTO_ROUTE_PHASE_CHAINS: dict[str, tuple[str, ...]] = {
+    "map-resume": ("map-resume",),
+    "map-check": ("map-check",),
+    "map-fast": ("map-fast",),
+    "map-plan": ("map-plan", "map-efficient", "map-check", "map-review"),
+    "map-efficient": ("map-efficient", "map-check", "map-review"),
+}
+
 # Chain-level retry bound: at most ONE re-entry per phase -- attempt 1
 # (first record) plus attempt 2 (the single permitted re-entry) are allowed;
 # a 3rd record of the same phase name is refused by record_auto_phase.
 AUTO_PHASE_MAX_ATTEMPTS = 2
 
 
+def _auto_route_final_phase(route: object) -> str | None:
+    """Return the last phase of `route`'s chain, or None for an unknown route.
+
+    record_auto_phase uses this to keep "this phase completed" and "the whole
+    route completed" separate (issue #621). A missing or unrecognized route
+    fails closed (returns None), so an unknown route can never be treated as
+    completed by a phase record.
+    """
+    if not isinstance(route, str):
+        return None
+    chain = AUTO_ROUTE_PHASE_CHAINS.get(route)
+    return chain[-1] if chain else None
+
+
 def auto_route_artifact_path(branch: str | None = None) -> Path:
     """Return the branch-scoped /map-auto routing decision artifact path."""
     return get_branch_dir(branch) / "auto-route.json"
@@ -20447,11 +20478,16 @@ def record_auto_phase(
 
     On every non-refused call, chain_status transitions from the recorded
     `status` using a closed vocabulary (AUTO_PHASE_TERMINAL_SUCCESS_STATUSES
-    -> "completed", AUTO_PHASE_ABORT_STATUSES -> "aborted", otherwise
-    "in_progress") and the `abort_reason` field is set/cleared to match. The
-    `auto_route` manifest stage is refreshed on every call (refused or not)
-    so progress is observable outside the artifact, with its status
-    mirroring the resulting chain_status.
+    -> "completed" when the phase is the LAST phase of the route's chain,
+    AUTO_PHASE_ABORT_STATUSES -> "aborted", otherwise "in_progress") and the
+    `abort_reason` field is set/cleared to match. Phase completion and route
+    completion are separate: a multi-phase route (map-plan, map-efficient)
+    stays "in_progress" after map-plan/map-efficient/map-check completes and
+    closes only on map-review; a single-phase route (map-resume, map-check,
+    map-fast) closes on its only phase. AUTO_ROUTE_PHASE_CHAINS is the single
+    source for each route's ordered chain. The `auto_route` manifest stage is
+    refreshed on every call (refused or not) so progress is observable outside
+    the artifact, with its status mirroring the resulting chain_status.
 
     `evidence_refs` persists caller-supplied ids (e.g. hold ids
     auto-approved by `auto_decide_holds`) in the phase entry, giving every
@@ -20562,7 +20598,14 @@ def record_auto_phase(
     artifact["phases"] = phases
 
     if status in AUTO_PHASE_TERMINAL_SUCCESS_STATUSES:
-        chain_status = "completed"
+        # Issue #621: a phase completing is not the route completing. Only the
+        # LAST phase of the routed chain closes chain_status; earlier completed
+        # phases keep the chain in_progress so the next phase is accepted
+        # instead of being refused by the terminal-chain guard below.
+        if phase == _auto_route_final_phase(artifact.get("selected_route")):
+            chain_status = "completed"
+        else:
+            chain_status = "in_progress"
     elif status in AUTO_PHASE_ABORT_STATUSES:
         chain_status = "aborted"
     else:

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

@@ -74,7 +74,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.
 
@@ -86,8 +86,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.1 → mapify_cli-3.35.2}/src/mapify_cli/templates/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.1 → mapify_cli-3.35.2}/src/mapify_cli/templates/skills/map-release/SKILL.md

@@ -74,7 +74,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.1 → mapify_cli-3.35.2}/src/mapify_cli/templates/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.1 → mapify_cli-3.35.2}/src/mapify_cli/templates_src/map/scripts/map_step_runner.py.jinja

@@ -19586,20 +19586,51 @@ _AUTO_ROUTE_NEXT_COMMAND: dict[str, str] = {
 
 # /map-auto phase ledger (issue #414): closed status vocabulary for
 # record_auto_phase's chain_status transitions. A phase status in
-# AUTO_PHASE_TERMINAL_SUCCESS_STATUSES completes the chain; a status in
-# AUTO_PHASE_ABORT_STATUSES aborts it; any other status leaves the chain
-# in_progress. These two sets are intentionally NOT required to partition
-# every possible status string -- callers may pass phase-specific statuses
-# (e.g. "monitor_rejected") that fall through to in_progress.
+# AUTO_PHASE_TERMINAL_SUCCESS_STATUSES completes the ROUTE only when that
+# phase is the last phase of the routed chain (see AUTO_ROUTE_PHASE_CHAINS); a
+# status in AUTO_PHASE_ABORT_STATUSES aborts the chain; any other status
+# leaves the chain in_progress. These two sets are intentionally NOT required
+# to partition every possible status string -- callers may pass phase-specific
+# statuses (e.g. "monitor_rejected") that fall through to in_progress.
 AUTO_PHASE_TERMINAL_SUCCESS_STATUSES = frozenset({"completed"})
 AUTO_PHASE_ABORT_STATUSES = frozenset({"aborted", "failed"})
 
+# /map-auto routed phase chains (issue #621): phase completion and route
+# completion are separate. A route reaches chain_status="completed" only when
+# the completed phase is the LAST phase of the chain its selected_route drives.
+# map-resume, map-check and map-fast are single-phase routes; map-plan and
+# map-efficient are multi-phase routes that continue through map-check and
+# close on map-review. Keeping the table beside the terminal-status vocabulary
+# makes the route/phase split explicit instead of inferring "completed" from
+# the phase status alone (the #446 regression).
+AUTO_ROUTE_PHASE_CHAINS: dict[str, tuple[str, ...]] = {
+    "map-resume": ("map-resume",),
+    "map-check": ("map-check",),
+    "map-fast": ("map-fast",),
+    "map-plan": ("map-plan", "map-efficient", "map-check", "map-review"),
+    "map-efficient": ("map-efficient", "map-check", "map-review"),
+}
+
 # Chain-level retry bound: at most ONE re-entry per phase -- attempt 1
 # (first record) plus attempt 2 (the single permitted re-entry) are allowed;
 # a 3rd record of the same phase name is refused by record_auto_phase.
 AUTO_PHASE_MAX_ATTEMPTS = 2
 
 
+def _auto_route_final_phase(route: object) -> str | None:
+    """Return the last phase of `route`'s chain, or None for an unknown route.
+
+    record_auto_phase uses this to keep "this phase completed" and "the whole
+    route completed" separate (issue #621). A missing or unrecognized route
+    fails closed (returns None), so an unknown route can never be treated as
+    completed by a phase record.
+    """
+    if not isinstance(route, str):
+        return None
+    chain = AUTO_ROUTE_PHASE_CHAINS.get(route)
+    return chain[-1] if chain else None
+
+
 def auto_route_artifact_path(branch: str | None = None) -> Path:
     """Return the branch-scoped /map-auto routing decision artifact path."""
     return get_branch_dir(branch) / "auto-route.json"
@@ -19817,11 +19848,16 @@ def record_auto_phase(
 
     On every non-refused call, chain_status transitions from the recorded
     `status` using a closed vocabulary (AUTO_PHASE_TERMINAL_SUCCESS_STATUSES
-    -> "completed", AUTO_PHASE_ABORT_STATUSES -> "aborted", otherwise
-    "in_progress") and the `abort_reason` field is set/cleared to match. The
-    `auto_route` manifest stage is refreshed on every call (refused or not)
-    so progress is observable outside the artifact, with its status
-    mirroring the resulting chain_status.
+    -> "completed" when the phase is the LAST phase of the route's chain,
+    AUTO_PHASE_ABORT_STATUSES -> "aborted", otherwise "in_progress") and the
+    `abort_reason` field is set/cleared to match. Phase completion and route
+    completion are separate: a multi-phase route (map-plan, map-efficient)
+    stays "in_progress" after map-plan/map-efficient/map-check completes and
+    closes only on map-review; a single-phase route (map-resume, map-check,
+    map-fast) closes on its only phase. AUTO_ROUTE_PHASE_CHAINS is the single
+    source for each route's ordered chain. The `auto_route` manifest stage is
+    refreshed on every call (refused or not) so progress is observable outside
+    the artifact, with its status mirroring the resulting chain_status.
 
     `evidence_refs` persists caller-supplied ids (e.g. hold ids
     auto-approved by `auto_decide_holds`) in the phase entry, giving every
@@ -19932,7 +19968,14 @@ def record_auto_phase(
     artifact["phases"] = phases
 
     if status in AUTO_PHASE_TERMINAL_SUCCESS_STATUSES:
-        chain_status = "completed"
+        # Issue #621: a phase completing is not the route completing. Only the
+        # LAST phase of the routed chain closes chain_status; earlier completed
+        # phases keep the chain in_progress so the next phase is accepted
+        # instead of being refused by the terminal-chain guard below.
+        if phase == _auto_route_final_phase(artifact.get("selected_route")):
+            chain_status = "completed"
+        else:
+            chain_status = "in_progress"
     elif status in AUTO_PHASE_ABORT_STATUSES:
         chain_status = "aborted"
     else:

{mapify_cli-3.35.1 → mapify_cli-3.35.2}/src/mapify_cli/templates_src/skills/map-auto/SKILL.md.jinja

@@ -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 `<% cmd %>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. `<% cmd %>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. `<% cmd %>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. `<% cmd %>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.1 → mapify_cli-3.35.2}/src/mapify_cli/templates_src/skills/map-auto/auto-reference.md.jinja

@@ -16,7 +16,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
 
@@ -36,10 +36,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.1 → mapify_cli-3.35.2}/src/mapify_cli/templates_src/skills/map-release/SKILL.md.jinja

@@ -72,7 +72,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.1 → mapify_cli-3.35.2}/src/mapify_cli/templates_src/skills/map-release/release-reference.md.jinja

@@ -36,11 +36,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.1 → mapify_cli-3.35.2}/tests/test_locking.py

@@ -468,6 +468,10 @@ def test_existing_lock_dir_mode_enforced(
 
     lock_root = tmp_path / ".map" / "locks"
     lock_root.mkdir(mode=0o755, parents=True)  # too permissive
+    # mkdir(mode=...) is filtered through the process umask, so a restrictive
+    # umask (e.g. 0o077) would create 0o700 and fail the precondition below.
+    # Set the broad mode explicitly to keep the test's intent umask-independent.
+    os.chmod(str(lock_root), 0o755)
     # Verify the broad mode is actually in place before we call.
     pre_mode = os.stat(str(lock_root)).st_mode & 0o777
     assert pre_mode == 0o755, f"Setup precondition failed: {oct(pre_mode)}"