Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
There was a problem hiding this comment.
Pull request overview
Updates the Amara 4th courier absorb doc to align terminology and counts with the actual tables/sections, and to soften “verbatim” claims where annotations are present.
Changes:
- Aligns action-item section wording with P1/P2/P3 coverage and updates Stabilize-stage item counts.
- Renames the “implementation artifacts” heading to reflect proposal-flag annotations.
- Updates the risk-matrix control term from
decision-proxy-consulttodecision-proxy-evidenceand renames the drift-class subheading to “five drift classes”.
…ed' soften Five Codex post-merge findings on the merged Amara memory-drift absorb: 1. decision-proxy-consult vs decision-proxy-evidence (line 282): Risk matrix used 'decision-proxy-consult' while action items + examples consistently use 'decision-proxy-evidence'. Aligned to '-evidence' (the canonical artifact name). 2. 'preserved verbatim' claim (line 99): Section heading said artifacts were 'preserved verbatim' but recent edits added proposal-flag annotations (PROPOSED notes on tools/memory/reconcile.py + tools/hygiene/check-memory-loop.sh). Renamed to 'preserved with proposal-flag annotations' which accurately describes the current state. 3. Drift-class subheading (line 320): Subheading said 'On the four drift classes' but the doc defines 5 (3 inside-loop + 2 outside-loop). Renamed to 'On the five drift classes (3 inside-loop + 2 outside-loop)'. 4. P1-P2 sections claim (line 69): Text said extracted items target P1-P2 but the table has a P3 row (Provenance evidence bundles). Updated to 'P1, P2, and P3 sections (one P3 row covers the longest-horizon Provenance evidence bundles work)'. 5. Stabilize item count (line 395): 'NOT' list said '4 S-effort items' but table lists 3 Stabilize items (2 S + 1 M). Updated to '3 items: 2 S-effort + 1 M-effort'.
…gment Two Codex post-merge findings on PR #430: (line 72) — table contains in-flight row not covered by 'BACKLOG candidates' framing: The intro said the table is BACKLOG candidates spanning P1-P3, but Memory duplicate-title lint is tagged 'in-flight' (landed elsewhere via PR #12). Updated intro to note the in-flight row explicitly: 'BACKLOG candidates spanning P1, P2, and P3 sections plus one in-flight row tracking work that already landed elsewhere'. (line 400) — orphaned line wrap: 'are the' was on its own line as a wrap artifact, making the sentence harder to read. Reflowed so 'right next tick or two' joins the prior line.
AceHack
force-pushed
the
drain/221-followup-2-terminology-and-counts
branch
from
ec79c85 to
afa7c5c
Compare
This was referenced Apr 25, 2026
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…w-up) (#462) Otto-268 follow-on: drain-log for the 3-finding cascade PR #431 (post-merge follow-up to #268 BLAKE3 receipt-hashing v0 design). Captures three substantive cryptographic-protocol design improvements: 1. `issuance_epoch` field added (8 → 9 → 10 field-count evolution across review waves; cross-epoch replay resistance during protocol upgrades). Backdating-limitation section also got 3 mitigations (RFC 3161 TSA / Aurora-anchored chained timestamps / forward-only registry). 2. Per-design-element attribution preservation (Amara's original vs Otto's refinement vs joint synthesis with Aaron's directive). 3rd observation of the verbatim-vs-annotation pattern (#235 + #430 + #431). 3. `parameter_file_sha` algorithm specification: BLAKE3 default; `hash_version` field determines algorithm for forward- compatibility. Same algorithm-agility-via-version-field pattern. Per Otto-250 training-signal discipline. Pattern observations: - Cryptographic-protocol design iterates through fields (8 → 9 → 10) across review waves. Each addition fixes a specific adversary class. - Algorithm-agility-via-version-field is the standard pattern (`hash_version`, `*_key_version`, `parameter_file_sha`-tied-to- `hash_version`). - Per-design-element attribution preservation is a recurring class (now 3 observations: #235 / #430 / #431). - Codex functioning as cryptographic-design reviewer is a high- value capability surface.
This was referenced Apr 25, 2026
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…dex) Otto-268 follow-on: drain-log for the 4-finding cascade PR #430 (post-merge follow-up to #221 Amara 4th courier ferry absorb). Captures four substantive Codex post-merge corrections. Per Otto-250 training-signal discipline. Pattern observations: 1. Verbatim-claim accuracy under absorbing-side annotation — "preserved verbatim" claims must reflect any absorbing-side annotations (proposal-flag markers, footnotes, inline bracketing). Same shape as #235's "byte-for-byte ... excluding whitespace" contradiction fix. 2. Count-vs-list cardinality is now a 4th-observation pattern (#191 / #219 / #430 / #85). At this density, pre-commit-lint candidate: regex on "N drift classes / phases / audits / items" patterns + count the surrounding list to verify. 3. Terminology drift between parent absorb + canonical vocabulary ("decision-proxy-consult" vs canonical "decision-proxy-evidence") is recurring. Fix template: align absorption-notes text to canonical; preserve verbatim ferry content per Otto-227. 4. Stabilize effort-summary correction is a concrete instance of "claim summary doesn't match per-item tally" — future doc-lint candidate (sum-vs-tally check).
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…rain-log Multiple Codex/Copilot threads on #461 caught: - L7 'Thread count at drain: 3' → '4' (body has Threads 1-4). - L17 'Codex caught three findings' → 'four' matching body. - L122 'merged to main' → 'merged to main as `5698f9d`' for consistency with other drain-logs that include the merge SHA for auditability. Same count-vs-list cardinality pattern (Class B in PR #465 doc-lint suite BACKLOG row) — 5th instance in my own drain-logs (#195 / #231 / #377 / #135 / #430). The pattern is genuinely universal author- side; even when explicitly aware of it, instances slip through.
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…dex) (#461) * hygiene(#268+): pr-preservation drain-log for #430 (#221 follow-up Codex) Otto-268 follow-on: drain-log for the 4-finding cascade PR #430 (post-merge follow-up to #221 Amara 4th courier ferry absorb). Captures four substantive Codex post-merge corrections. Per Otto-250 training-signal discipline. Pattern observations: 1. Verbatim-claim accuracy under absorbing-side annotation — "preserved verbatim" claims must reflect any absorbing-side annotations (proposal-flag markers, footnotes, inline bracketing). Same shape as #235's "byte-for-byte ... excluding whitespace" contradiction fix. 2. Count-vs-list cardinality is now a 4th-observation pattern (#191 / #219 / #430 / #85). At this density, pre-commit-lint candidate: regex on "N drift classes / phases / audits / items" patterns + count the surrounding list to verify. 3. Terminology drift between parent absorb + canonical vocabulary ("decision-proxy-consult" vs canonical "decision-proxy-evidence") is recurring. Fix template: align absorption-notes text to canonical; preserve verbatim ferry content per Otto-227. 4. Stabilize effort-summary correction is a concrete instance of "claim summary doesn't match per-item tally" — future doc-lint candidate (sum-vs-tally check). * drain(#461 follow-up): fix count mismatches + add merge SHA in #430 drain-log Multiple Codex/Copilot threads on #461 caught: - L7 'Thread count at drain: 3' → '4' (body has Threads 1-4). - L17 'Codex caught three findings' → 'four' matching body. - L122 'merged to main' → 'merged to main as `5698f9d`' for consistency with other drain-logs that include the merge SHA for auditability. Same count-vs-list cardinality pattern (Class B in PR #465 doc-lint suite BACKLOG row) — 5th instance in my own drain-logs (#195 / #231 / #377 / #135 / #430). The pattern is genuinely universal author- side; even when explicitly aware of it, instances slip through.
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
#464) * hygiene(#268+): pr-preservation drain-log for #426 (tick-history meta-record) Otto-268 follow-on: drain-log for the **meta-record** PR #426 (tick-history append summarizing the 28-thread sustained-drain-wave on 2026-04-25T04:15:00Z). The wave-summary itself attracted 3 post-merge findings on text accuracy. Per Otto-250 training-signal discipline. Pattern observations: 1. Tick-history meta-records get drained too — drain corpus is recursive. Every PR that lands gets reviewer-cascade attention regardless of substantive vs meta content. 2. Otto-229 append-only correction-row pattern applied uniformly: original row stays untouched; correction rows point back at the original timestamp. 3. Pipe-in-Markdown-table-row is a recurring formatting class — inline code spans containing `|` get parsed as column separators. Earlier `||` issues + MD056 hits; #426 has it with `|` in a `read -rs | printf` command. Pre-commit-lint candidate. 4. Count-vs-list cardinality observed at 5 PRs now (#191, #219, #430, #85, #426). Pattern is mature enough that automation would pay back across the entire drain corpus. * hygiene(#464): align intro PR-list with canonical (a)-(h) enumeration Codex P2: intro listed 6 PRs as the wave scope but the canonical (a)-(h) enumeration in Thread 1 covers 8 PRs (#414, #422, #423, #425, #268, #270, #126, #133). Same count-vs-list cardinality pattern documented in _patterns.md Class B (Otto-268). Reword intro to match the authoritative 8-PR list.
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
* backlog: P2 doc-lint suite — recurring drain-finding classes promoted Compounding-substrate work on Otto-268+ drain-log corpus: three findings classes from `docs/pr-preservation/_patterns.md` have reached observation density warranting pre-commit-lint automation. Classes promoted to BACKLOG: A. Inline-code-span line-wrap (4 PRs: #191, #195, #219, #423). Regex check for backtick spans crossing newlines. B. Count-vs-list cardinality (5 PRs: #191, #219, #430, #85, #426). Regex on "N items / phases / audits / drift classes / PRs" patterns + count surrounding list + warn on mismatch. C. Pipe-in-Markdown-table-row (3+ PRs). Regex check on table rows for unescaped `|` inside code spans. Effort: M. Each class ~20-50 lines of regex + tests. Could land as separate scripts or combined `tools/lint/doc-lint.sh`. Wire into pre-commit + gate.yml per existing lint-script convention. Composes with lower-density candidate classes (D-F) from the multi-CLI capability-map cluster + shellcheck-rule-ID precision + stable-identifier-vs-line-number xref — promote when density justifies. References `docs/pr-preservation/_patterns.md` (PR #448). Compounding with Otto-114 forward-mirror substrate fix: structural change converts per-PR fix-toil into never-recurring class. The 3+ existing classes have already paid for themselves in verify-and-resolve replies; pre-commit-lint catches future instances at author-time. * hygiene(#465): fix 3 Copilot findings on the doc-lint BACKLOG row - P1 :4481 — Class B regex example: keep `\b\d+\s+...\b` on a single line of backticks (was crossing newline, rendering as two adjacent spans rather than one regex; ironically a Class A pattern instance inside the Class A description). - P2 :4488 — Class C: cite markdownlint rule by full identifier `MD056/table-column-count` (consistent with how it's recorded in docs/pr-preservation/141-ci-fix-log.md:35; helps grep-ability). - P2 :4501 — keep `stable-identifier-vs-line-number` contiguous (was hard-wrapped mid-token as `stable-identifier-vs-line-` / `number`, rendering as 'line- number' with extra space). All three findings are pattern instances of classes this same BACKLOG row promotes to lint-suite candidates — appropriate self-application.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Codex post-merge review on PR #221 surfaced 5 substantive findings.