eblume/blumeops
1
1
Fork 0
Code Issues Pull requests Projects Releases 83 Packages Wiki Activity Actions

Formalize C0/C1/C2 change classification #259

Merged
eblume merged 8 commits from formalize-change-classification into main 2026-02-23 16:19:54 -08:00
Conversation 1 Commits 8 Files changed 8 +2 -5
1 changed files with 2 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 738a0c82e1 - Show all commits

Address PR feedback: simplify invariant rule, drop 'prior chains'

Prev Next 
- Remove "prior Mikado chains" from C1 doc search step — completed
  chains are just documentation, not a special category
- Collapse the two "not allowed" bullets into a single rule: no card
  may be introduced after any code or card-closing commit

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Erich Blume 2026-02-23 15:46:55 -08:00
commit 738a0c82e1

7
docs/how-to/agent-change-process.md
View file

@ -42,7 +42,7 @@ A change with enough complexity or risk that a human should review it, but not s
### Process
1. Run `mise run ai-docs` to load context
2. **Search related docs** — read existing documentation, reference cards, and prior Mikado chains related to the change area
2. **Search related docs** — read existing documentation and reference cards related to the change area
3. **Create a feature branch** and open a PR early (draft is fine)
4. **Documentation first** — commit doc changes reflecting the desired end state before writing code. This helps the reviewer understand intent and catches design issues early
5. **Implement** — commit code changes, pushing as you go. The PR gets updated along the way and the user can review and comment at any point
@ -84,10 +84,7 @@ main ← [card commits] ← [code, close] ← [code, close] ← ... ← [finaliz
3. A cycle should target a single leaf node (though closing multiple in one cycle is acceptable if the code supports it)
4. Cycles repeat until the chain is complete
**What is NOT allowed:**
- Introducing a new Mikado card after any code or card-closing commit (new cards require a branch reset — see below)
- Closing a Mikado card before all cards it depends on have been introduced
**The one rule:** No Mikado card may be introduced after any code or card-closing commit. New cards require a branch reset (see below).
**The length-zero case:** It is valid for the "planning layer" to have zero commits on the branch — this happens when all Mikado cards were introduced in earlier sessions and are already in main's history. The invariant is satisfied.
eblume marked this conversation as resolved
eblume commented 2026-02-23 15:42:09 -08:00
Copy link

honestly this feels like a weaker version of the previous rule, no? Let's think about how we can express this invariant as succinctly as possible. It occurs to me that there's another possibility we haven't precluded, which is a commit that closes a mikado leaf node PRIOR to the code which resolves that leaf node. This would imply that we closed a leaf node that wasn't actually done. Not sure it needs to be called out... the rule is just "don't close mikado leaf nodes that aren't done" I guess? Probably not worth calling out.

honestly this feels like a weaker version of the previous rule, no? Let's think about how we can express this invariant as succinctly as possible. It occurs to me that there's another possibility we haven't precluded, which is a commit that closes a mikado leaf node PRIOR to the code which resolves that leaf node. This would imply that we closed a leaf node that wasn't actually done. Not sure it needs to be called out... the rule is just "don't close mikado leaf nodes that aren't done" I guess? Probably not worth calling out.