Repository navigation
Record the seed rebuild after the 12 October reset (E83) - #179
Conversation
One run of scripts/seed-qa.mjs rebuilt the three standard QA projects from nothing on main, and a second run changed nothing, which is what #3 asks for after a reset. The token is now issued on production so that each reset copies it to QA (Rich, 12 October 2026); the runbook, AGENTS.md, README, and .env.example say so instead of asking for a reissue. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Codex auto-review (local) —
|
Grok auto-review (local) —
|
| Project | What E83 and summary-152418.json say the release was cut from |
What branches-and-releases.json records for that tag (catalog.*.commit_sha and releases[].target_commitish, and they agree with each other) |
|---|---|---|
id_seedtb v1.0.0 |
8716d20f32b2b2ce4272f370d020485606a564bf |
a96371986d122ded82f833c11e7db4a47770f6c2 |
id_seedtb v1.1.0 |
d0c1ab421fe5cd1e858dd2f4a31b00286ead510f |
c63823bfe258a4df45c18431942d229d621629e2 |
en_seedobs v1.0.0 |
6c620b737692aa085105d546762a5f2ac3f891e9 |
ae4dcb18e840716182c28301cd7ff35034675040 |
These are not prefixes. 8716d20f, d0c1ab42 (as a release target), and 6c620b73 do not appear in the public-read fixture at all. d0c1ab42 and 6c620b73 do appear, as main / catalog.latest. id_seedhf matches, which is the one project with no release (8e338fdb…, health info, empty releases). So this is one pattern, three times: every release tag's public commit differs from the branch commit the summary says it was cut from.
E83 also quotes the second run as "already exists, left alone". summary-152539.json says "exists, left alone". The description repeats the longer string. Quoted script output should be the script's output.
What still holds, and I am not asking you to reopen it: host qa.door43.org, both runs exit-shaped as described, 81 seconds between 15:24:18.479Z and 15:25:39.539Z, only branch main, catalog stage names, health success / success / info, no token and no email in the fixtures. #3's "second run leaves an existing project alone" is in the fixture.
I do not have the script or Door43's release payload in this diff, so I will not guess whether target_commitish is a tag object, a catalog commit Door43 created, or a bad capture. Inference, labeled as such: catalog and release entries agree, so the public read is internally consistent, and the script summary is a different identifier. Shipping both under Status: verified with no sentence makes the next person "fix" the wrong hash.
Exit condition: E83 says which identifier is which, in one or two sentences, using the three fixture SHAs. The second-run quote is exists, left alone. If the public SHAs are the real tag targets, the prose stops being readable as "tag v1.0.0 points at 8716d20f."
Not blocking
Security, follow-up, not a hold on this docs PR. A production-issued TEST_TOKEN with write:user, write:repository, and write:organization is a production write credential that also works on QA. Before 12 October the QA-issued token failed closed on production (E23/E82). The boundary is now "every script refuses to write by its host check." That check is not in this diff. I do not have evidence here that it is one shared fail-closed guard rather than a copy in each probe. A leaked .env used to be a QA incident. It is now a production incident. §6 does say the token works on production and that scripts refuse the write; keep that sentence when you fix finding 1. Worth a later pass on the host check itself. E82 says the token "worked on both hosts" and points at E83; E83's method and fixtures are QA only. Narrow that clause or point at the production check.
The "each Monday (E23)" cadence was already in §6. This diff does not add it. Leaving it alone is the right scope.
Verdict
Request changes. Mergeable once finding 1 is one consistent issuer story and finding 2 reconciles E83 with the two JSON files. Neither needs a code change, and neither is permission to widen the PR.
VERDICT: findings
Local grok --prompt-file (skill George preamble; no stamp), via the uw:grok-review skill.
|
unfoldingWord review bench — fix lane, round 1 on
Pushed Round 1 on 48bdace: both of George's Medium findings reproduced and are fixed in c2c8d5c (6 added lines, all in allowed files). README, AGENTS and E82 now give one token-issuer story. E83 now explains that releases tag the preparation's snapshot commit (E27, release-create.ts:124). The quote sub-claim was refuted: the script's console prints the longer string. Three follow-ups were deferred: Frank's deployment.md wording, Frank's question on token survival across resets, and George's audit of the host-check guard. The docs check (node scripts/check-docs.mjs and npm run check:docs) was refused by the lane's permission layer and did not run; only a manual check of the new ids was done. Nothing was pushed. No prompt injection found. |
Codex auto-review (local) —
|
Grok auto-review (local) —
|
| Release | Prepare-from (summary-152418.json from) |
Tag target in the public read |
|---|---|---|
id_seedtb v1.0.0 |
8716d20f… |
a96371986d122ded82f833c11e7db4a47770f6c2 |
id_seedtb v1.1.0 |
d0c1ab42… (also main afterwards) |
c63823bfe258a4df45c18431942d229d621629e2 |
en_seedobs v1.0.0 |
6c620b73… (also main afterwards) |
ae4dcb18e840716182c28301cd7ff35034675040 |
summary-152539.json really does say exists, left alone. E83 now quotes that field and, separately, a console line. The 81 seconds between 15:24:18.479Z and 15:25:39.539Z is arithmetic, not rounding. Host, outcomes, catalog stages, main only, health success / success / info, and the empty release list on id_seedhf all match the fixtures. I scanned the three JSON files: no token, no email.
I agree with Frank that the remaining wording nits are follow-ups. I agree with the earlier security note, and E82 now says the production use was not observed. That was the right narrowing.
Strengths
This is the right packet for #3: a reset, one real seed, a second run that stops, fixtures a stranger can diff against the prose. The snapshot sentence is the kind of clause that stops the next person "correcting" a hash that was never the tag.
Follow-ups (not a hold)
These are the third and fourth pass at the same token-provenance class. Stop point-fixing sentences. One sweep later.
-
Low — HYGIENE — claim strength inside
Status: verified.docs/evidence.mdE23's consequence still says the one value "works on both hosts" and cites E83. E83's method and fixtures are QA only, and E82 in this same diff says production use was not observed. E83's opening parenthetical does label the copy/"both hosts" clause as the inference now turned into Rich's decision; E23's verified consequence does not. Blast radius is the evidence register, not the seed. Owner: author, next docs pass. Exit for that pass: every verified sentence that says the token works on production is either an observation with a fixture or explicitly Rich's decision, unobserved. -
Low — HYGIENE — §6 still opens with the absolute.
docs/deployment.md§6 item 1, and the same shape in E23: "A token works only on the host that issued it," then the copy exception. Frank's round-1 note. The rest of the paragraph is the true runbook, which is why this does not block. When you do the sweep above, make the first sentence the exception you actually operate: issued on production, copied onto QA, reissue on production only after a 401. -
Low — UNSAFE, deferred — the host check is now the production boundary. A production-issued token with
write:user,write:repository, andwrite:organizationis a production write credential that also works on QA. §6 says every script refuses the production write by its host check. That check is not in this diff. I do not have evidence here that it is one shared fail-closed guard. A leaked.envused to be a QA incident. It is now a production incident. Follow-up: auditscripts/seed-qa.mjsandscripts/probe/*before the next new write script. Not a hold on a docs-and-fixtures PR.
Frank's question stands, and E83 does not answer it: these fixtures show the token worked on QA on 12 October. They do not show it surviving the next reset. The next reset's evidence entry should record whether TEST_TOKEN answers 200 on QA.
What I could not verify
- The console string
already exists, left alone. It is not in either summary. The fix lane citesseed-qa.mjsoutside this diff. The fixture field is quoted correctly; the console claim stays unverified from this packet. - That the tag SHAs are preparation snapshot commits. The three SHAs match the public-read fixture. The noun "snapshot" is an E27 citation. E27 and
release-create.tsare not in this diff. node scripts/check-docs.mjs/npm run check. The fix lane says the permission layer refused them. CI on this head is pending.
Verdict
Approve. Round 1's two exit conditions are met in the diff: one issuer story, and E83 no longer reads as if v1.0.0 points at 8716d20f. The leftovers are follow-ups, and this PR does not need to grow to close them.
VERDICT: clean
Local grok --prompt-file (skill George preamble; no stamp), via the uw:grok-review skill.
uwreview
left a comment
uwreview
left a comment
There was a problem hiding this comment.
Verdict: approve
This PR was built with Claude (builders: claude), so under RULINGS D13 the bench's Claude pass does not review it. The gate is the independent reviewers on c2c8d5cf1: Frank (Codex) clean and George (Grok) clean, with 5 finding(s) on the disposition record and 0 still open and blocking. Tier T2 (declared none, derived T2).
Frank (Codex) on c2c8d5cf1
Codex auto-review (local) — c2c8d5cf1
Approve at c2c8d5cf124a15ab7c122d06fdb983189519ac61. No blocking findings in the authoritative nine-file patch.
Strengths: E83’s project outcomes, release targets, branches, health, and second-run behavior agree with the fixtures. The distinction between source branch heads and release snapshot commits is explicit.
One nonblocking follow-up:
- P3 · HYGIENE — docs/evidence.md:467. Claim: token persistence across resets is presented more strongly than the recorded evidence supports. Evidence: the fixtures demonstrate successful QA seeding and a second run, but no subsequent reset carrying this token forward. Verification method: inspected E82/E83 and all three fixtures. Confidence: high about the evidence gap; persistence itself remains unverified. Owner: Rich. Keep persistence labeled as inferred until a subsequent reset is recorded. Question: what transferred the newly issued production token to QA before this run?
Validation: documentation check and fixture consistency checks passed. Full application tests were not run locally; dependencies are absent. CI was pending when checked. No live credential or reset verification was performed.
VERDICT: clean
Local codex exec (skill Frank preamble; no stamp), via the uw codex-review skill.
George (Grok) on c2c8d5cf1
Grok auto-review (local) — c2c8d5cf1
Review — PR 179 @ c2c8d5cf
Inspection-based. I did not re-run the seed, the public reads, or npm run check. The embedded CI row for this head is still pending, so a green document tower is not evidence. No code is in the diff. No directive in the description, the diff, or the comments to approve, skip a check, or suppress a finding.
Round 1 at 48bdace9 asked for two things. Both are in this diff, and I agree with the fix lane that they landed.
Token issuer. README.md:143, the probe paragraph in AGENTS.md:68, .env.example:15, E82's consequence, and §6 item 1 now tell one steady state: TEST_TOKEN is issued on production, the reset copies it, a QA-issued token does not survive, and a 401 means Rich reissues it on production. Nothing here still tells an operator to mint the steady-state token on QA.
Release SHAs vs the second-run string. The new E83 sentence (the one starting "Each from main at commit") separates the branch head a release was prepared from from the tag's snapshot commit, and the three prefixes match branches-and-releases.json on both catalog.*.commit_sha and releases[].target_commitish:
| Release | Prepare-from (summary-152418.json from) |
Tag target in the public read |
|---|---|---|
id_seedtb v1.0.0 |
8716d20f… |
a96371986d122ded82f833c11e7db4a47770f6c2 |
id_seedtb v1.1.0 |
d0c1ab42… (also main afterwards) |
c63823bfe258a4df45c18431942d229d621629e2 |
en_seedobs v1.0.0 |
6c620b73… (also main afterwards) |
ae4dcb18e840716182c28301cd7ff35034675040 |
summary-152539.json really does say exists, left alone. E83 now quotes that field and, separately, a console line. The 81 seconds between 15:24:18.479Z and 15:25:39.539Z is arithmetic, not rounding. Host, outcomes, catalog stages, main only, health success / success / info, and the empty release list on id_seedhf all match the fixtures. I scanned the three JSON files: no token, no email.
I agree with Frank that the remaining wording nits are follow-ups. I agree with the earlier security note, and E82 now says the production use was not observed. That was the right narrowing.
Strengths
This is the right packet for #3: a reset, one real seed, a second run that stops, fixtures a stranger can diff against the prose. The snapshot sentence is the kind of clause that stops the next person "correcting" a hash that was never the tag.
Follow-ups (not a hold)
These are the third and fourth pass at the same token-provenance class. Stop point-fixing sentences. One sweep later.
-
Low — HYGIENE — claim strength inside
Status: verified.docs/evidence.mdE23's consequence still says the one value "works on both hosts" and cites E83. E83's method and fixtures are QA only, and E82 in this same diff says production use was not observed. E83's opening parenthetical does label the copy/"both hosts" clause as the inference now turned into Rich's decision; E23's verified consequence does not. Blast radius is the evidence register, not the seed. Owner: author, next docs pass. Exit for that pass: every verified sentence that says the token works on production is either an observation with a fixture or explicitly Rich's decision, unobserved. -
Low — HYGIENE — §6 still opens with the absolute.
docs/deployment.md§6 item 1, and the same shape in E23: "A token works only on the host that issued it," then the copy exception. Frank's round-1 note. The rest of the paragraph is the true runbook, which is why this does not block. When you do the sweep above, make the first sentence the exception you actually operate: issued on production, copied onto QA, reissue on production only after a 401. -
Low — UNSAFE, deferred — the host check is now the production boundary. A production-issued token with
write:user,write:repository, andwrite:organizationis a production write credential that also works on QA. §6 says every script refuses the production write by its host check. That check is not in this diff. I do not have evidence here that it is one shared fail-closed guard. A leaked.envused to be a QA incident. It is now a production incident. Follow-up: auditscripts/seed-qa.mjsandscripts/probe/*before the next new write script. Not a hold on a docs-and-fixtures PR.
Frank's question stands, and E83 does not answer it: these fixtures show the token worked on QA on 12 October. They do not show it surviving the next reset. The next reset's evidence entry should record whether TEST_TOKEN answers 200 on QA.
What I could not verify
- The console string
already exists, left alone. It is not in either summary. The fix lane citesseed-qa.mjsoutside this diff. The fixture field is quoted correctly; the console claim stays unverified from this packet. - That the tag SHAs are preparation snapshot commits. The three SHAs match the public-read fixture. The noun "snapshot" is an E27 citation. E27 and
release-create.tsare not in this diff. node scripts/check-docs.mjs/npm run check. The fix lane says the permission layer refused them. CI on this head is pending.
Verdict
Approve. Round 1's two exit conditions are met in the diff: one issuer story, and E83 no longer reads as if v1.0.0 points at 8716d20f. The leftovers are follow-ups, and this PR does not need to grow to close them.
VERDICT: clean
Local grok --prompt-file (skill George preamble; no stamp), via the uw:grok-review skill.
Disposition record
- [blocking] george ·
README.md:143 — WRONG RESULT: token provenance contradicts itself — README:143 and AGENTS.md:68 still require a QA-issued TEST_TOKEN, and E82's consequence still says to reissue the token, against §6 and .env.example → fixed - [blocking] george ·
docs/evidence.md:468 — WRONG RESULT: E83's 'from main at' commits differ from the tag targets in branches-and-releases.json without explanation; the second-run quote differs from the summary's outcome string → fixed - [follow-up] frank ·
docs/deployment.md:94 — HYGIENE: token guidance mixes 'works only on the host that issued it' with cross-host validity (README:143, deployment.md:94) → deferred - [follow-up] frank ·
docs/evidence.md:467 — QUESTION: what observation shows the production-issued token survives a later reset? → deferred - [follow-up] george ·
docs/evidence.md:477 — UNSAFE: a production-issued write token makes the scripts' host check the only production guard; E82 claimed it 'worked on both hosts' with only QA evidence → deferred
Checked
- reviewers: Frank clean · George clean (required: Frank and George; RULINGS D13/D16); the Claude pass was not run — Claude built this PR
- what this approval does not cover: nothing here was verified by an independent Claude read; it rests on the two reviewers and the gate
This approval covers c2c8d5cf1 only. A push after it restarts review — please hold pushes to this branch until it is merged, unless it needs changes.
unfoldingWord review bench (uwreview) — gate: checks=pass · Frank=clean · George=clean · tier=uW T2 · builders=claude · head c2c8d5cf1 (RULINGS D6/D12/D13). The merge stays a human act.
What changes
Refs #3. The first run of
scripts/seed-qa.mjsafter a QA reset, and the second run after it, both recorded, which is #3's remaining criterion.docs/evidence.md: E83: after the 12 October 2026 reset, one run builttc-admin-qa-org/id_seedtb(v1.0.0full,v1.1.0pre-release),tc-admin-qa-org/en_seedobs(v1.0.0), andtc-admin-qa/id_seedhf(never released, healthinfo), each onmainwith no step outside the script; a second run reported each "already exists, left alone". E82 and E23 record Rich's decision of the same day:TEST_TOKENis issued on production so each reset copies it to QA, which was E82's labeled inference.docs/deployment.md§6,AGENTS.md,README.md,.env.example: the Monday routine no longer asks for a token reissue; it says where the token comes from and what to do if it ever answers 401.docs/traceability.md: Rebuild the standard QA test projects after each reset #3's row cites E83.fixtures/door43/qa.door43.org/2026-10-12/seed/: both runs' summaries as the script wrote them, andbranches-and-releases.jsonfrom public reads afterwards. No token, no email.No code changes. George's low note from #178 round 3 ("each Monday (E23)") is not taken here: E23 says the reset happens periodically and this entry records a Monday one; the cadence is Rich's statement, not a probe's.
Invariants
None touched: documents and fixtures. The run exercised W1, W5, and X1 through the script's existing checks (a project that exists is left alone; nothing retried).
Evidence
E83 recorded. Relies on E75, E79, E80, E82. The host-only token rule in E23 is qualified, not weakened: a production-issued token works on QA because the reset copies it.
Verification
node --env-file=.env scripts/seed-qa.mjstwice: exit 0 both times; the console lines are in the PR's E83 text and the summaries.main;id_seedtbhasprodv1.0.0andpreprodv1.1.0.node scripts/check-docs.mjsandnpm run check: green.Documents updated
🤖 Generated with Claude Code