Skip to content

docs(rules): supply the fork lens from an always-loaded pointer - #126

Merged
jakewan merged 4 commits into
mainfrom
feature/fork-lens-values
Sep 27, 2026
Merged

jakewan merged 4 commits into
mainfrom
feature/fork-lens-values

Conversation

@jakewan

@jakewan jakewan commented Sep 27, 2026 •

Copy link
Copy Markdown
Owner

Overview

The UI decision rubric carried the project's design-fork-adjudication supply, but ui-decisions.md loads only when a file under app/** 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.

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
jakewan marked this pull request as ready for review September 27, 2026 16:18
@jakewan

jakewan commented Sep 27, 2026

Copy link
Copy Markdown
Owner Author

Review disposition · head 4e6df37

  • Codex: no marked Codex verdict found.
  • Copilot: no Copilot round.
  • Approvals: no standing review.

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.

@jakewan
jakewan merged commit fdf0d50 into main Sep 27, 2026
3 checks passed
@jakewan
jakewan deleted the feature/fork-lens-values branch September 27, 2026 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant