agents: one item only -- the title's animation timing -- and split work into human-checkable units
Some checks failed
CI / Native — ubuntu-latest (push) Failing after 7m49s
CI / WASM — Web (push) Failing after 6m37s
CI / Formatting (push) Failing after 53s
CI / Native — macos-latest (push) Has been cancelled
CI / Native — windows-latest (push) Has been cancelled

Two new findings from the human, both about WHEN a title animation starts, and
both handed over rather than guessed:

F5 Does (A) SNAP the title to finished, or ACCELERATE it? The human says they
   cannot tell and is right that they cannot -- a three-frame acceleration and a
   one-frame cut look identical to an eye. Two routes that should agree: a
   per-frame capture (acceleration shows intermediate alphas, a cut shows none)
   and the code (assigning a target time and raising a rate multiplier are
   different instructions). Their "looks more like a snap on multiple attempts"
   is recorded as a PRIOR, not a result.

F6 The title's sweeping white glow -- ptloop01/ptloop02, the blue PCB-like lines
   -- starts only when the plate appears in the real game, and starts earlier in
   the port. A lead from the exported declaration, mine and unverified: those
   elements are keyed at t = 0, 70, 100, 238, 250 while the plate reaches full
   alpha at 236, with pteff02 keyed at exactly 236 and ptlogo_back2eff and
   ptcopyright at 238. 236-238 is a synchronisation point in the declared data
   and a human just reported a behaviour change there. Flagged AGAINST itself
   too: 238...250 looks equally like an exit ramp -- ptcopyright uses that shape
   and starts nothing -- and the sweep lives in a nested .rat leaf with its own
   timeline.

F6 bears on clock: "shared" and on F4: if a title element does not move until
the plate arrives, either the declared data says so and our keyframe reading is
wrong, or something at the plate's arrival STARTS it, which is a mechanism
nobody has proposed.

And the process change, which is the human's and outlives this item:

  "attacking the 'whole' mission was too big for them to handle. Split the given
   missions and tasks into even smaller tasks which they can tackle and give to
   a human for feedback."

PROTOCOL.md gains "Work in units a human can check in a minute". A milestone is
not a unit of work, it is a bag of them. A unit is right-sized when it ends in
something a person can judge in under a minute WITHOUT READING ANYTHING, and
each one states its question, what the human looks at, and what it does NOT
cover. Do one, hand it over, stop -- an unverified fix under a second change
makes a regression two-variable.

The evidence for the rule is this week: the splash sat through a whole milestone
and took one day once scoped to "does it animate?". The bar is a HUMAN check,
not a green tool -- three instruments passed a frozen screen.
This commit is contained in:
MechaCat02
2026-09-02 20:14:46 +02:00
parent 6438316f24
commit fee2e4278a
4 changed files with 179 additions and 0 deletions

View File

@@ -152,6 +152,45 @@ asking X"** rather than approximating. An approximation from the wrong agent
arrives with no classification attached and is indistinguishable from a
measurement a month later.
## Work in units a human can check in a minute
**Set by the human, 2026-09-02, from what actually worked.** The splash bug had
sat through a whole milestone. Scoped to *one* question — *does it animate?* — it
was found, fixed, verified and signed off in a day.
> *"I think attacking the 'whole' mission was too big for them to handle. Split
> the given missions and tasks into even smaller tasks which they can tackle and
> give to a human for feedback."*
So: **a milestone is not a unit of work. It is a bag of them.** Before starting,
split it, and pick one.
A unit is right-sized when it ends in something **a person can judge in under a
minute without reading anything**. Not "P6 audio" — *"the confirm SFX is no
longer louder than the music; listen once."* Not "the title screen" — *"the glow
starts when the plate appears; watch one boot."*
Each unit, written down **before** the work:
* **the question**, as one sentence a non-expert could answer;
* **what the human looks at**, and what pass and fail each look like;
* **what it does NOT cover** — the neighbouring thing you are deliberately not
fixing, so nobody reads a narrow pass as a broad one.
Then: **do that one, hand it over, and stop.** Do not run ahead into the next
unit while the first is unverified — an unverified fix underneath a second change
is how a regression becomes two-variable and unattributable.
⚠️ **The bar is a HUMAN check, not a green tool.** Three instruments passed a
frozen screen. A tool answers *did my change do what I intended*; only the person
answers *is it right*. When a unit needs a look, say so plainly and say what to
look at — an ask that is buried in a document nobody opens is not an ask.
📌 And this bounds the writing, which has been the other failure: the retro found
`DECISIONS.md` past 13 000 lines while the gate did not move. **A unit's record
is proportional to the unit.** If explaining it takes longer than doing it, the
unit was too big or the writing is doing something other than explaining.
## Publishing
* Commit to `auto/<topic>`; a human merges.