hertz -> doyle. FIVE FILES COMMITTED, TRACEABILITY RUN, PREDICTIONS FILED — and the CLI version you asked me to name turns out to be the finding.

COMMITS, tip 61bfd85c, tree CLEAN:
  2072b467  ci: traceable-reqs floor 0.2.0 -> 0.4.0 for placement enforcement
  c3b5feec  ci(golden): gate the docs axis on its own prerequisites, and pin 0.4.0
  56f4185c  test: cross-node serving e2e pinned to bound ports and the node-root redirect
  15234229  test: detach the real rc viewer by its keybind, not by killing it
  61bfd85c  test(twohost): bound the probe rendezvous separately from the ceremony wait
Each message names its REQ; the workflow ones name the observable they change.

YOUR ci.yml QUESTION ANSWERED — IT IS NOT A RIDER. The lane's manifest gained a
[placement] section at 33936943: enforce = "on", module_banner = "accept". 0.2.0 does
not implement it. golden.yml's own pin comment says so in the same words ("v0.4.0 adds
per-tag placement enforcement; manifest policy deliberately accepts existing module
banners while enforcing placement elsewhere (IR-37)"), so both floors are load-bearing
for the same lane feature and I committed them as one subject across two files.

NOW THE PART THAT MATTERS. `traceable-reqs --version` on this box is 0.2.0. So EVERY
local check I have run today — including the one you asked me to run just now — HAS
BEEN IGNORING THE PLACEMENT POLICY THIS LANE TURNED ON. Measured rather than assumed:
the run emits no placement finding, no unknown-key warning and no unsupported-section
diagnostic; all 40 occurrences of the word in its output are inside requirement TITLE
prose. It reads the section and says nothing.
So my local green on placement is not a green, it is a silence — the same clean-zero
shape as my grep an hour ago, this time in the tool I have been quoting as a gate. CI
at 0.4.0 will enforce something my local runs have never checked, and the first time
anyone sees a placement verdict on this lane will be in CI unless someone installs 0.4.0
here first. I am not installing it inside a window; say if you want that done and when.

CHECK AT THE TIP, named as you asked: `traceable-reqs check`, CLI 0.2.0, tip 61bfd85c,
REAL EXIT 1 (captured directly, not through a pipe — the earlier EXIT=0 I reported this
morning was `tail`'s status, not the tool's). Two findings, both known and both owned
elsewhere:
  [must] missing_stage REQ-WEB-LAN-BOOTSTRAP-FIREWALL stage=int  — todlando deactivates
         this row on his branch per your ruling; it is not deactivated on mine.
  [must] missing_stage REQ-WEB-URL-BOUND-PORT stage=unit — waits on his port_from_status
         and may_fall_back splits, which I author against once they land.
Neither is new and neither is mine to close at this tip. Both resolve at assembly.

PREDICTIONS FILED BEFORE ANY RUN at .spt/preserved/hertz-304-w1-c468e9df/predictions-61bfd85c.txt,
eight lines, each with the reason it rests on so a wrong one is diagnostic:
  webserve_e2e 1-5: GREEN, all five. Your three UNKNOWNs are now read line by line —
    the subnet-label case never touches the index and its redirects are BARE-NODE ones
    (no trailing slash -> /local/), a different arm from the node-root-to-docs one;
    the directory-roots case and the adapter-docs-facet case touch no retired surface.
  attach_link_push_e2e: GREEN, LOWEST CONFIDENCE of the set. The clause now ends a real
    `spt rc` viewer with a piped ctrl-b d instead of a kill, and the load-bearing
    assumption is that a piped non-console stdin reaches rc's BYTE reader rather than
    its Windows key-event path. rc has both; which one a pipe lands on I have not
    measured end to end. If it reds, check the input channel before anything else.
  webserve_cross_node_e2e: GREEN for the peer-URL case; SECOND-LOWEST for the serve_add
    bound-port arm, because a discovery that resolves the wrong NODE fails there as a
    byte mismatch rather than as a port bug.
  twohost_web.rs: NO PREDICTION OFFERED. Two-machine rig, compile-gated only, labelled
    hole in my END, closed by the #297 two-machine leg.

Ready to re-inventory on todlando's END. Nothing of mine running.