Twinned from https://github.com/cfsh/ninefold/issues/1079 by tools/beads/import_github.py's reconcile pass.
Follow-up to #1077 (this PR: #1078), which renamed "Tier 0"/"Tier-0" out of
every .md doc — design 009 reserved the word "tier" for
NINEFOLD_PHILOSOPHY.md's hacky-vs-hardened investment tiers, and the
reviewer's own comment-only-authority sense of "Tier 0" now collides with
design 009's unrelated, shipped "Tier 1" merge authority.
#1077 was scoped to *.md files only (its own test plan grepped
--include='*.md'). A wider grep across the whole tree turns up the same
"Tier-0" vocabulary live in Python source — docstrings, CLI help strings, and
inline comments — which #1077 never touched:
``` $ grep -rniE "tier.?0|tier-0" --include='*.py' . ```
turns up ~30 hits across dev.py, tools/nflib/devcli.py,
tools/nflib/perimeter.py, tools/nflib/verdict.py, tools/reviewer/engine.py,
tools/pr/review_now.py, tools/pr/merge_pr.py, tools/perimeter_census.py,
and several *_test.py files. Two different flavors, worth separating:
1. Live, current-tense descriptions — e.g. dev.py:8 and
tools/nflib/devcli.py:7,1527,1801,2169: ./dev.py review 's own help
text and its "Next: … — pull the Tier-0 review when you are ready" printed
output, and tools/reviewer/engine.py:2's module docstring "Tier-0 review
engine for ninefold-reviewer". These describe what the tool does *today*,
the same class of sentence #1077 renamed in the docs.
2. Historical citations — e.g. tools/pr/merge_pr_test.py's many
`"""⚠ Tier-0 F1, and #830 — the incident this whole change descends
from""", tools/nflib/perimeter.py:14-16`'s changelog-style comments
("R1's shared/ half — Tier-0 review, on the observation that…"), and
tools/nflib/verdict_test.py:87's doc-quoting test. These cite a
*specific finding from a specific past review round* by an ID
(Tier-0 F1, Tier-0 F3) — closer to notes/history.md's case law than
to live description, and may be legitimate to leave as historical
identifiers rather than rename.
Same rule as #1077: rename every live, current-tense "Tier 0"/"Tier-0"
occurrence to plain vocabulary (reuse "comment-only" where that's the sense,
matching #1078's renames in the docs these files reference). For each
historical-citation occurrence, judge case by case whether it is a
genuine finding-ID citation (leave it, same reasoning as notes/history.md)
or just leftover prose that happens to be inside a comment (rename it). Start
from grep -rniE "tier.?0|tier-0" --include='*.py' . (rerun fresh — #1078
may have shifted line numbers) and go file by file.
⚠️ Some of these sites sit inside tools/nflib/, which is GOVERNANCE
(perimeter-protected) — the PR waits for Aedan regardless of how small the
diff is.
- grep -rniE "tier.?0|tier-0" --include='*.py' . after the change: only
hits that were deliberately kept as historical finding-IDs, each one
judged in the PR body or a comment explaining why.
- ./presubmit.py --all green — these are docstring/comment/help-string
edits; no behavior change expected, but several sites are inside files
with contract tests (test_nflib_verdict.py reads CHARTER.md, not these
files, so unaffected) — run the suite to confirm nothing else pins the
exact string.
Same as #1077: the perimeter's own "Tier 1"/"Tier 2" merge-authority naming
(tier1_authority() and friends) is out of scope — design 009 kept that
vocabulary deliberately.
One PR, mechanical (E3) — unless the historical-citation judgment calls turn out to need real back-and-forth, in which case split live-description renames (mechanical) from historical-citation renames (judgment) into two.
1. **Rename the Tier-0 F1/Tier-0 F3 finding-ID citations, or leave them
as historical identifiers? Default: leave them** — they name a
specific finding from a specific past review round, the same class of
fact notes/history.md preserves verbatim; renaming risks implying the
finding happened under some other authority than it did. Ships this way
unless whoever implements this finds a cleaner ID scheme.
None.
No comments.