Repository navigation
docs(rules): supply the fork lens from an always-loaded pointer - #126
Merged
Merged
Conversation
ui-decisions.md loads only under app/**, so a UI fork discussed while planning never reached it. A small always-loaded rule now carries the design-fork-adjudication supply and points at the rubric, which stays path-scoped; the rubric records which lens decided a lean rather than which settled the fork.
Rewording "settled" to "lean" left two sibling spans telling the reader to "decide in the open", which reads as permission to decide the UX-versus-engineering trade while showing the work. That trade is the case most likely to need the maintainer, so both spans now surface the choice with a lean.
The rubric's example still described the record-transaction form as unbuilt, though it shipped alongside the rubric and the example asked to be replaced once it did. Now that an always-loaded pointer sends planning sessions to the rubric, the stale claim was read exactly when app context was least available to correct it. The example now cites the shipped files, and names the Qt rule by path because that rule is path-scoped and is not in context at planning time.
The pointer said "user-facing" in one sentence and "UI" in the next, under a heading broader than both. In finch the MCP tools and gRPC API are user-facing too, so a reader could apply screen-level lenses to a tool-shape fork. It also read as if the UX lenses were the only thing a fork is weighed on, though the rubric sets an engineering axis beside them.
jakewan
marked this pull request as ready for review
September 27, 2026 16:18
Owner
Author
|
Review disposition · head 4e6df37
Reason: merged without an independent pass. This is a small prose change to two agent rule files, and every factual claim in the changed text was checked against the files it cites. Scope: this records the review state at merge, not the handling of review findings that have no comment thread. |
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
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.
Overview
The UI decision rubric carried the project's
design-fork-adjudicationsupply, butui-decisions.mdloads only when a file underapp/**is read. A UI fork discussed while planning, before any app file is open, therefore never reached it. A small always-loaded rule,design-forks.md, now carries the supply and points at the rubric, which stays path-scoped. The pointer is scoped to the Qt app's UI; MCP tool and API forks get no lens from it.The rubric now records which lens decided the lean rather than which lens settled the fork, and it surfaces lens-vs-lens and UX-versus-engineering conflicts as a choice with a lean rather than deciding them, so the maintainer can still engage or overturn the lean.
Because planning sessions now reach the rubric with no app file open, its worked example describes the shipped record-transaction form rather than unbuilt work, and it names the path-scoped Qt rule by path.