[problem] wr-architect mark-oversight-confirmed writes unmatchable markers: hashes the path as given, and misses the main session ID in multi-agent sessions

[tompahoward]

Description

Writing human-oversight: confirmed into an ADR's frontmatter is gated by architect-oversight-marker-discipline.sh (PreToolUse on Edit and Write). The hook permits the edit only when /tmp/oversight-confirmed-<sha256-first16-of-ABSOLUTE-path>-<session_id> exists, where session_id comes from the hook's own stdin and the hash is computed from the ADR's absolute path. The companion wr-architect-mark-oversight-confirmed command is what writes that marker after a confirmation lands. Two bugs stop it matching:

1. The mark command hashes the path argument as given. Passing a repo-relative path (docs/decisions/029-....md) produces a marker keyed by the relative-path hash, while the hook keys by the absolute-path hash. The marker never matches, the edit stays blocked, and the command still prints success.

2. Session-ID discovery misses the main session. Even with an absolute path, the mark command writes the marker only under candidate session IDs it discovers by mtime-scanning /tmp/*-announced-* markers. In a multi-agent session those candidates are the subagents' IDs. The hook reads the main session's session_id from its own stdin, which is not in that discovered set.

Hit 2026-07-08 while ratifying two ADRs in a session with architect, JTBD, and risk-scorer subagents running concurrently: 21 markers were written, none under the ID the hook read, and the edit stayed blocked.

Symptoms

• wr-architect-mark-oversight-confirmed reports success, and the subsequent Edit is still denied by the discipline hook.
• With a relative path argument, the marker filename's hash component does not match the hash the hook computes for the same file.
• In a multi-agent session, markers land under subagent session IDs while the hook reads the main session's ID from stdin.

Workaround

Pass the ADR's absolute path to wr-architect-mark-oversight-confirmed. If the Edit is still blocked, hand-write the marker for each candidate session UUID (readable from scratchpad and task-output paths):

H=$(printf '%s' "$ABS_ADR_PATH" | shasum -a 256 | cut -c1-16)
touch /tmp/oversight-confirmed-$H-<session-uuid>

then retry the Edit.

Affected plugin or component

@windyroad/wr-architect: the wr-architect-mark-oversight-confirmed command, against architect-oversight-marker-discipline.sh.

Frequency

Every ADR ratification where the mark command is given a relative path. The multi-agent case fired on the one session observed (2026-07-08); on the stated mechanism it should recur in any session with concurrent subagents, which the plugin suite's own gates routinely spawn.

Versions

• Local plugin: @windyroad/wr-architect@0.20.2
• Upstream package: @windyroad/wr-architect@0.20.2
• Claude Code CLI: 2.1.219 (Claude Code)
• Node: v24.16.0
• OS: Darwin 25.3.0 x86_64

Evidence

Suggested fix, two parts:

1. Normalise the path argument to an absolute path inside the mark command before hashing, so callers cannot get this wrong.
2. Resolve the current session ID the same way the discipline hook does, reading the authoritative runtime session-ID source rather than mtime-scanning announce markers. Failing that, write the marker under every plausible candidate including the one the hook will actually read.

Part 2 is the same multi-agent session-ID-resolution root class as the @windyroad/itil SID-helper picking a subagent UUID. The two helpers sit in different plugins but want the same resolution rule.

Additional context

The failure is silent from the caller's side. The command's success output and the hook's denial are the only two signals, and neither names the mismatch. Echoing the computed marker path on success would make the relative-path case self-diagnosing.

Cross-reference

Reported from the downstream addressr project; tracked locally as P046 in its docs/problems/ directory.

[tompahoward]

Seeing this from https://github.com/voder-ai/dry-aged-deps — tracked locally as P032.

Additional context

A third failure mode of the same mark-oversight-confirmed helper (both the wr-architect- and wr-jtbd- variants), distinct from the two bugs described above: the 24h mtime window on the announce-marker candidate enumeration ages out a session's OWN announce marker when the session runs longer than 24h. The helper then writes the /tmp/oversight-confirmed-<sha>-<sid> marker only under recent OTHER sessions' SIDs, never the live one; the gate (reading the live SID from the Write's stdin) finds no match and blocks the born-confirmed ADR/JTBD Write with no substance-confirm evidence marker exists. The AskUserQuestion substance-confirm genuinely happened — only the marker-SID bookkeeping is wrong.

Observed on a session spanning 2026-07-07 to 07-11 (>24h). ls /tmp/oversight-confirmed-* shows markers under UUIDs that are not the current session's SID.

Zero-code workaround: export SESSION_CANDIDATE_WINDOW_MINS=<large> (widen the -mmin window past the session age) or export CLAUDE_SESSION_ID=<live-sid> (the helper's env-var fast path) before running the helper. Fix shape: widen or replace the 24h window, or always include the live SID (env-var / runtime-sid) in the candidate set regardless of announce-marker age.