Conversation
Two rules and one sharpening, from a coaching engagement that authored an implementation plan from a settled design. Before specifying a capability as work, check whether this project already has it. The existing absence rule governs verdicts; this one governs plans. A framework that lacks a capability does not mean the project lacks it: a component can already implement the framework's extension point, measured, with its edge cases handled. A plan that respecifies working code wastes the build and invites a rewrite that loses behaviour nobody wrote down. Before filing a finding, check whether the record already records it. A design record that names something as a deliberate trade has settled it. Reporting it as newly found sends the sponsor to re-decide what they decided, and buries the findings that are real. The finding is then "revisit this recorded trade", citing the passage, with the cost stated and no verdict. Self-lint item 4 is sharpened rather than added to. It already said sweep every artifact. What it lacked is that the sweep is mechanical over every file, never over the files the change touched, and that a word whose meaning a ruling changed is as much a defect as an instruction it reversed. The engagement record and the evidence behind each rule stay in the coach's own repository, which is private. This repository gets the rules only.
patelanil
force-pushed
the
coach/round-5-architect-rules
branch
from
August 16, 2026 17:00
f04d9da to
e027b1f
Compare
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
1 participant
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.
Two rules and one sharpening, from a coaching engagement that authored an implementation plan from a settled design.
This repository is public, so it carries the rules only, worded generically. The engagement record, the evidence and the project names stay in the coach's own private repository.
Before specifying a capability as work, check whether this project already has it
The existing absence rule governs verdicts. This one governs plans.
A framework that lacks a capability does not mean the project lacks it. A component can already implement the framework's extension point, measured, with its edge cases handled. A plan that respecifies working code wastes the build, and invites a rewrite that loses behaviour nobody wrote down.
Before filing a finding, check whether the record already records it
A design record that names something as a deliberate trade has settled it. Reporting it as newly found sends the sponsor to re-decide what they decided, and it buries the findings that are real.
If the record has it, the finding is "revisit this recorded trade", citing the passage, with the cost stated and no verdict.
One sharpening rather than a third rule
Self-lint item 4 already said sweep every artifact. What it lacked is that the sweep is mechanical over every file, never over the files the change happened to touch, and that a word whose meaning a ruling changed is as much a defect as an instruction it reversed.
Scope
One file,
agents/moqui-architect.md, eighteen lines added.An earlier revision of this branch also appended an engagement record to
docs/architect-skill-spec.md. That named a client repository and internal class names in a public repo, which is against the coach method's own rule. It has been removed and the branch force-pushed. The record now lives in the private repository instead.Not verified, and worth stating
The method requires replaying the role's eval fixtures after any change to this file. The two fixtures its spec names were never written, so the replay has never run for this role and did not run here. Writing them is owed work.
Not touched
The plugin version, still
0.11.0.