docs(rules): add UI Decision Rubric for design forks#83
Merged
Conversation
Establish a durable lens-based rubric for settling user-facing design forks, so they are decided by a shared standard rather than ad-hoc each time. Supplies the design-fork-adjudication extension point, scoped to UI work, and path-conditioned to app/** so it loads when UI code is in play. The rubric was derived outside-in from a real placement decision (where a transaction-recording form should live), carried as an illustrative worked example until that form ships. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Overview
Establishes a durable, lens-based rubric for settling user-facing design forks, so they are decided by a shared standard rather than ad-hoc each time. The rule supplies the
design-fork-adjudicationextension point scoped to UI work, and is path-conditioned toapp/**so it loads when UI code is in play.The five lenses — locality of action, pattern consistency, input economy, forgiving input, discoverability — are listed in rough priority, with a separate engineering-constraints axis that UX leads but never silently loses to. The rubric was derived outside-in from a real placement decision (where a transaction-recording form should live), carried as an explicitly illustrative worked example until that form ships.
How it works
Mirrors the sibling
qt-app.md:paths: "app/**/*"frontmatter, public-surface-clean prose, standalone-readable without the slot marker. The accepted trade-off — it won't auto-load during pure UI planning that hasn't yet touched an app file — is recorded in the plan; the consuming planning rule routes to this supply deliberately.Related to #38.