Skip to content

[AUTOMATED] docs(re-needs): restore 14 round-3 records I deleted - #424

Merged
mahaloz merged 1 commit into
mainfrom
docs/restore-round3-records
Sep 5, 2026
Merged

[AUTOMATED] docs(re-needs): restore 14 round-3 records I deleted#424
mahaloz merged 1 commit into
mainfrom
docs/restore-round3-records

Conversation

@mahaloz

@mahaloz mahaloz commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

I destroyed these and am putting them back. Round 3's gate admitted 23 observations
which clustered into 16 needs; only 2 reached main. The other 14 are here.

WHAT I DID. Preparing an unrelated change I ran git add docs/re-needs/ while the
loop had 17 round-3 records written but not yet committed. That staged them onto my
branch, making them tracked THERE and not on main. Switching back to main then
deleted them from the working tree -- correct git behaviour, and silent. The deletion
happened on a later, unrelated command, which is why nothing looked wrong at the time.
I noticed only when the round-3 need count read 2 instead of 16.

Recovered whole from the orphaned commit 8b3e8dc; all 51 records pass
needs.validate() and the index reindexes to 51 (35 closed, 16 open).

WHY IT MATTERED. _recently_shipped and the backlog are both built from these
records, so round 4's tester brief would have omitted a round of findings and its
builders would have had 14 fewer needs to work -- including two crashes
(ssa-renaming-panics-protected, block-processing-panics-out), the corrupt-ELF
loader gap, and the --define-function boundary defect.

WHAT NOT TO REPEAT. docs/re-needs/ and docs/re-pipeline.md are shared journals
that the loop and an operator both append to; this is the third collision there this
session and the first destructive one. Never git add <dir> in them -- name files.
And after any branch switch in a repo where another agent is working, verify its
UNTRACKED files are still present: committing someone's untracked work is invisible
at the time and removes it later.

This commit stages the 14 restored records and the reindexed index.json, and
deliberately leaves the three records the loop is editing right now
(checker-exceeds-instruction-ceiling, large-function-malformed-output,
prototype-assertions-reject-ordinary) uncommitted, for it to land itself.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

🤖 Generated with Claude Code

https://claude.ai/code/session_01YcFmfZndNjgfqLQVBZCdkY

I destroyed these and am putting them back. Round 3's gate admitted 23 observations
which clustered into 16 needs; only 2 reached main. The other 14 are here.

WHAT I DID. Preparing an unrelated change I ran `git add docs/re-needs/` while the
loop had 17 round-3 records written but not yet committed. That staged them onto my
branch, making them tracked THERE and not on main. Switching back to main then
deleted them from the working tree -- correct git behaviour, and silent. The deletion
happened on a later, unrelated command, which is why nothing looked wrong at the time.
I noticed only when the round-3 need count read 2 instead of 16.

Recovered whole from the orphaned commit 8b3e8dc; all 51 records pass
`needs.validate()` and the index reindexes to 51 (35 closed, 16 open).

WHY IT MATTERED. `_recently_shipped` and the backlog are both built from these
records, so round 4's tester brief would have omitted a round of findings and its
builders would have had 14 fewer needs to work -- including two crashes
(`ssa-renaming-panics-protected`, `block-processing-panics-out`), the corrupt-ELF
loader gap, and the `--define-function` boundary defect.

WHAT NOT TO REPEAT. `docs/re-needs/` and `docs/re-pipeline.md` are shared journals
that the loop and an operator both append to; this is the third collision there this
session and the first destructive one. Never `git add <dir>` in them -- name files.
And after any branch switch in a repo where another agent is working, verify its
UNTRACKED files are still present: committing someone's untracked work is invisible
at the time and removes it later.

This commit stages the 14 restored records and the reindexed index.json, and
deliberately leaves the three records the loop is editing right now
(checker-exceeds-instruction-ceiling, large-function-malformed-output,
prototype-assertions-reject-ordinary) uncommitted, for it to land itself.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@mahaloz
mahaloz merged commit b4796f8 into main Sep 5, 2026
9 checks passed
@mahaloz
mahaloz deleted the docs/restore-round3-records branch September 5, 2026 23:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant