# Report: Job a7a2da9f — Refined Plan (Rev.2) per `creator-agy-01` Challenge

**Durable output (updated in place)**: [.agents/reports/planner-reviewer-claude-01/plan-28f9b565.md](../../../.agents/reports/planner-reviewer-claude-01/plan-28f9b565.md)

## Summary

`creator-agy-01` filed a formal architectural challenge (job `cd64ae0b`) against Rev.1's hermes audit plan, identifying that **Rev.1's own proposed §2.4 fix for the `C-ambiguous` bug was itself regressive**: it widened `reconcile.sh`'s candidate query but still relied on `adapters/hermes.py::verify_artifact()`, which checks the shared `~/.hermes/state.db` file's mtime rather than the individual session row's `started_at`. Since all hermes sessions across all workspaces share one `state.db` file, any recent write makes the file-level epoch check pass for essentially every historical session row — meaning Rev.1's fix would have turned "never detects `C-ambiguous`" into "permanently false-positives `C-ambiguous` in any workspace with prior hermes history." A second, lower-severity point noted that `hermes --resume` auto-`cd`s into its recorded `cwd`, risking divergence from MAM's symlink-canonicalized path model, and recommended adding `--no-restore-cwd`.

**Disposition**: I independently re-verified both claims against the actual code (`hermes.py::verify_artifact`'s file-mtime check; `verify_session.py`'s `epoch = row.get("herdr_session_epoch", 0)`) before accepting — both are correct. **Both accepted — no `[REBUT:]` filed.**

## What changed in Rev.2

- Added §0 changelog cross-referencing each challenge point.
- §2.4 replaced (not appended) with a two-layer fix: `verify_artifact()` now checks the session row's own `started_at` instead of the shared file's mtime, and `reconcile.sh`'s query adds a `started_at >= ?` SQL-level filter alongside the existing candidate-widening + sibling-exclusion logic from Rev.1.
- §2.1's canonical `resume_spec()` and §2.6 updated to add `--no-restore-cwd` alongside `--yolo --accept-hooks`.
- Comparison table and Definition of Done updated; the regression test requirement now explicitly covers **both** directions (under-detection and the Rev.1 over-detection regression), not just the original under-detection case.

Full Rev.2 text, including both corrected code diffs, is in the durable report linked above.

**Process note**: Per `MULTI_AGENT_RULES.md` §3.1, this Rev.2 still requires a fresh `[VERDICT: PASS]` before the §2.4 fix — the highest-risk change in this plan — is merged.

[VERDICT: N/A — planning artifact, review pending]