Nothing records which correction produced which rule, so absorbed and open findings look identical #356

Open
opened 2026-08-26 02:31:18 +00:00 by coilyco-ops · 0 comments
Member

The structural finding from #351's follow-up read, and the one that reframes the rest.

What the read turned up

Four of the round-1 findings turn out to be already fixed. The human corrected the behavior in a session, and doctrine later changed to address it. Nobody recorded the link.

  • 151d05c5 2026-08-14T04:41:56Z - the human had to ask whether the seat could merge its own PRs. The workflow lane text now states explicitly that reading the merge lane as someone-else-merges-later inverts the lanes and strands finished work.
  • b88f60ea 2026-08-07T21:33:58Z - the human asked whether repo skills should carry their on-disk location. Shipped repo-* skills now open with that pointer.
  • fdfd9990 2026-08-17T23:28:28Z - the human asked why doctrine was not loaded on the first turn. The identity card now states that the summary is not the operative text and that each named skill must be loaded before acting.
  • 87a40dff 2026-08-12T00:17:22Z - the agent stopped at a dependency and reported. A finish-the-whole-task rule now says a task ends at a verifiable done-condition rather than at the first reportable milestone.

Why this matters more than any single axis

The loop already runs. It runs manually, through the human noticing a correction and later writing a rule, and on this evidence it works. What is missing is not the mechanism, it is the ledger.

Without one there is no way to tell an absorbed correction from an open one except by doing what this round did by hand: read the correction, read the current shipped text, and compare. That cost dominates the round. It also means:

  • the same finding gets re-derived every round, and re-ticketed
  • a rule cannot be traced back to the observation that justified it, so nobody can tell whether removing it is safe
  • the before-and-after in #351 cannot attribute a rate change to a specific fix, only to a date

What would resolve it

A durable link from a correction to the rule it produced. Shape is the owner's call. The minimum useful record is the citation already used in these issues, session id plus timestamp, against the doctrine change that answered it.

Acceptance conditions:

  • Given a doctrine rule, a reader can find the observation that motivated it, or see explicitly that none was recorded.
  • Given a round-1 style finding, a reader can tell whether it is already addressed without re-reading shipped doctrine.
  • The record survives the roster migration in #333 and #335, so it cannot be keyed to a file path or a KDL node.
  • Citations only. No verbatim transcript text, since this repository is public and the corpus is private conversation.

Note on scope

This is not asking for automation of the loop. The human-in-the-middle step is the part that works. It is asking that the step leave a trace.

Method and corpus in #351. Join key in #350.

The structural finding from #351's follow-up read, and the one that reframes the rest. ## What the read turned up Four of the round-1 findings turn out to be **already fixed**. The human corrected the behavior in a session, and doctrine later changed to address it. Nobody recorded the link. * `151d05c5` 2026-08-14T04:41:56Z - the human had to ask whether the seat could merge its own PRs. The workflow lane text now states explicitly that reading the merge lane as someone-else-merges-later inverts the lanes and strands finished work. * `b88f60ea` 2026-08-07T21:33:58Z - the human asked whether repo skills should carry their on-disk location. Shipped `repo-*` skills now open with that pointer. * `fdfd9990` 2026-08-17T23:28:28Z - the human asked why doctrine was not loaded on the first turn. The identity card now states that the summary is not the operative text and that each named skill must be loaded before acting. * `87a40dff` 2026-08-12T00:17:22Z - the agent stopped at a dependency and reported. A finish-the-whole-task rule now says a task ends at a verifiable done-condition rather than at the first reportable milestone. ## Why this matters more than any single axis **The loop already runs.** It runs manually, through the human noticing a correction and later writing a rule, and on this evidence it works. What is missing is not the mechanism, it is the ledger. Without one there is no way to tell an absorbed correction from an open one except by doing what this round did by hand: read the correction, read the current shipped text, and compare. That cost dominates the round. It also means: * the same finding gets re-derived every round, and re-ticketed * a rule cannot be traced back to the observation that justified it, so nobody can tell whether removing it is safe * the before-and-after in #351 cannot attribute a rate change to a specific fix, only to a date ## What would resolve it A durable link from a correction to the rule it produced. Shape is the owner's call. The minimum useful record is the citation already used in these issues, session id plus timestamp, against the doctrine change that answered it. Acceptance conditions: * Given a doctrine rule, a reader can find the observation that motivated it, or see explicitly that none was recorded. * Given a round-1 style finding, a reader can tell whether it is already addressed without re-reading shipped doctrine. * The record survives the roster migration in #333 and #335, so it cannot be keyed to a file path or a KDL node. * Citations only. No verbatim transcript text, since this repository is public and the corpus is private conversation. ## Note on scope This is not asking for automation of the loop. The human-in-the-middle step is the part that works. It is asking that the step leave a trace. Method and corpus in #351. Join key in #350.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-flight-deck/agent-compose#356
No description provided.