Proposal: one parameter object, before the third breaking change - #53
Open
syncytium2 wants to merge 2 commits into
Open
Proposal: one parameter object, before the third breaking change#53syncytium2 wants to merge 2 commits into
syncytium2 wants to merge 2 commits into
Conversation
simulate_coordination takes 25 keyword parameters. Four are the background model, and three of those four arrived in the last two days as it learned that real fields are uneven across ROIs and clumpy in time. The rate of change is the project working; the problem is that it arrives through every caller's call site, and the slow-epoch axis the data is already asking for makes it four. So: pass one object, and let it be the same object the fitting stage returns. Adding an axis then changes no call site for anyone who received a spec and handed it on, which is every stage of the workflow app. Honest about the limit — a caller that CONSTRUCTS a BackgroundModel by naming fields is as coupled as it is today; what changes is that the coupling becomes countable. The split that falls out is worth as much as the object. RecordingSpec describes a real recording and is fittable; the promiscuity probe and the distractors stay in the bench because they are test constructs nobody can measure from tissue. That is the generator/bench boundary held in code rather than in prose, after a week of the two being conflated in conversation — including by me, twice. Murderboarded, 11 roles, two rounds. It caught three wrong numbers, one of them a figure I had carried over from another session's plan without recomputing: 51-67% of the bench recording's rate is not background, which is actually 31-67% (67.2% quiet, 30.6% busy). Recomputed here with the method stated inline so the next reader need not trust this one either. Round two revised it against PR #46 landing and PR #48 opening under it. Three open questions are left open on purpose, because all three change what gets built and none is a session's to settle: whether recording shape belongs in the same object as the fitted models, whether the deprecation window earns its cost, and whether the bench moves onto a fitted background inside this change or after it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
syncytium2
pushed a commit
that referenced
this pull request
Aug 27, 2026
…o surface Two sessions closed together; this is the one file the next one reads. Root HANDOFF.md, because five PRs are in flight — #304, #292, #270 (red), #53, #50 — and `tests/test_handoff_is_honest.py` retires it when the last of them closes. MURDERBOARDED, 11 of 11 roles, 2 blind rounds, record in docs/reviews/HANDOFF_2026-08-27.md. The freshness gate stopped the run first, for the second time in three days — vendored 94d720c against upstream 73dad04 — so the family was re-vendored before any role ran. Roster unchanged at 11. THE TWO FINDINGS THAT MATTER WERE BOTH FOUND BY RUNNING SOMETHING. The handoff guard rejected the first draft. Its opening forty lines — the region the guard checks and the briefing shows — named exactly one PR, #298, which is closed. The page asserted "five PRs are open" in prose while the only machine-checkable thing where it counted was a dead one. The open PRs are named there now and it resolves all six live. Then the full suite caught the file starving the waiting-on-Tony list. ALARM_ROOM is a shared pool spent in emission order, and a root handoff renders first — correctly; it is the stop-something-is-in-flight line. This one is 601B, which left the list too little, and the third item's action line came out as "-> Did […]". That item is "did you mean to close PR #298" — one of the three decisions the page exists to put in front of a person. The handoff was cutting the decision list to make room for itself. The fix follows this file's own ALARM_ROOM comment, which already calls that trade backwards: the handoff is the safer thing to shorten, because its alarm says READ THE FILE and the reader is about to, while a decision request appears nowhere else. emit_bounded takes a RESERVE — a block that renders early is told what a later, less truncatable one needs and spends only the remainder. The ADR todo's waiting: line also went from 278B to 160B, three sentences where the convention is one. A SECOND TEST WAS WRITTEN FOR THIS AND DELETED. It counted action lines; the truncation cut the tail of the third line rather than the line, so the count never moved and it passed with the fix reverted. test_it_surfaces_work_that_is_finished_and_waiting_on_a_person already asserts the real property and fails without the reserve — verified in both directions. A guard nobody has watched fail is not a guard, and shipping a redundant one that cannot fire would have been this session's own criticism, committed. The budget could not just be raised. tools/hook_spill_census.sh, built by the other session from 55 real spill records, puts the threshold at (8962B, 10186B] and rates the 9,000B budget "ok, 1186B under the smallest refusal". No room to buy. ALSO: the machine-local board went from 12 ACTIVE claims to 4. The eight released held nothing — merged branches, reaped worktrees — and the briefing was showing them as live to every session that started. Suite 1,378 passed, 13 skipped. sapper clear. Briefing 8,962B against 9,000B, which the page states, because the next thing added to that hook degrades FOUNDATIONS §9. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Aug 27, 2026
syncytium2
pushed a commit
that referenced
this pull request
Sep 1, 2026
… rotting The root HANDOFF.md is read aloud at every session start. It claimed main at ced0da4 (37 commits back), the suite at 1,569 against 1,708 collected, and the board at "30 ACTIVE, 7 with a live worktree" against 39 ACTIVE of 275 with 29 having none. What makes this worth a commit rather than a quiet fix: the note directly beneath those figures, dated 2026-08-30, says "every figure above had rotted" and draws the general lesson -- "a file whose whole job is to say what is true cannot be checked only on its own retirement condition". Then it refreshed the numbers and left them there. Same file, same claim, wrong twice in three days, with the diagnosis printed underneath both times. So the counts come out rather than getting a third value. Each is one command and the commands are now in their place, alongside docs/MILESTONES.md for the durable question -- rows pinned to commits, which can go incomplete but cannot silently change their minds. RESET.md reached this first and says why: "those were wrong within the hour it took to draft this." The retirement gate is untouched and still cannot fire: #292, #53 and #50 are all open, so test_handoff_is_honest.py stays green no matter what this file says. That is a separate defect and it stays open. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
syncytium2
added a commit
that referenced
this pull request
Sep 1, 2026
… rotting (#437) The root HANDOFF.md is read aloud at every session start. It claimed main at ced0da4 (37 commits back), the suite at 1,569 against 1,708 collected, and the board at "30 ACTIVE, 7 with a live worktree" against 39 ACTIVE of 275 with 29 having none. What makes this worth a commit rather than a quiet fix: the note directly beneath those figures, dated 2026-08-30, says "every figure above had rotted" and draws the general lesson -- "a file whose whole job is to say what is true cannot be checked only on its own retirement condition". Then it refreshed the numbers and left them there. Same file, same claim, wrong twice in three days, with the diagnosis printed underneath both times. So the counts come out rather than getting a third value. Each is one command and the commands are now in their place, alongside docs/MILESTONES.md for the durable question -- rows pinned to commits, which can go incomplete but cannot silently change their minds. RESET.md reached this first and says why: "those were wrong within the hour it took to draft this." The retirement gate is untouched and still cannot fire: #292, #53 and #50 are all open, so test_handoff_is_honest.py stays green no matter what this file says. That is a separate defect and it stays open. Co-authored-by: richard defazio <defazio@umich.edu> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
2 participants
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.
Proposal for review. Nothing built.
docs/parameter_spec_proposal.md.The problem, as a number
simulate_coordinationtakes 25 keyword parameters. Four are the background model —bg_rate_hz,bg_rate_shape,bg_burst_shape,bg_burst_bin_sec— and three arrived in the last two days, as it learned that real fields are uneven across ROIs and clumpy in time. The slow-epoch axis the data is already asking for makes it four.That rate of change is the project working. The defect is that it arrives through every consumer's call site, and several sessions are building against this signature right now.
The change
Pass one object, and let it be the same object the fitting stage returns:
Honest about the limit: a caller that receives a spec and passes it on is insulated — that is every stage of the workflow app. A caller that constructs a
BackgroundModelby naming fields is as coupled as today. What changes is that the coupling stops being everywhere and becomes countable.The split that falls out
RecordingSpecdescribes a real recording and is fittable. The promiscuity probe and the distractors stay in the bench, because they are test constructs nobody can measure from tissue. That puts the generator/bench boundary in code instead of prose — after a week of the two being conflated in conversation, including by me, twice.Murderboard: 11 roles, two rounds
It caught three wrong numbers. The one worth naming:
51–67%of the bench recording's realized rate is not background — a figure I carried from another session's plan without recomputing. It is actually 31–67% (67.2% quiet, 30.6% busy). Recomputed here with the method stated inline, so the next reader need not trust this one either.Round two revised it against PR #46 landing (labels now carry realized onsets) and PR #48 opening (FOUNDATIONS §6 reversal) underneath it.
Three questions left open on purpose
All three change what gets built and none is a session's to settle: whether recording shape belongs in the same object as the fitted models; whether the deprecation window earns its cost against cutting the keywords now; and whether the bench moves onto a fitted background inside this change or after it.
376 passed, 1 skipped · sapper clear · roster 11/11.
🤖 Generated with Claude Code