CLAUDE/DESIGN/JOURNAL: design rationale ≠ implementation effort

User correction during the post-RC-overnight check-in: the 18a
"Type::Fn metadata vs. new Type variant" call was justified
across DESIGN.md, JOURNAL, and the commit message primarily by
"avoids ~250 match-arm sites". That is an observation about the
current state of the code, not a design rationale.

CLAUDE.md gains two binding rules:

- Design rationale ≠ implementation effort. Effort is at most a
  tiebreaker; a choice whose only stated reason is effort is
  suspect. The rule names the 18a misstep as the canonical
  anti-example so future sessions catch it earlier.
- Direction freedom + bounce-back conditions inlined (was
  previously a cross-reference to a private auto-memory file
  outside the repo, which the user couldn't see).

DESIGN.md Decision 10's Schema-additions block now leads with
the substantive reasons for per-position metadata: semantic
locality (modes belong to fn-parameter positions, not to types
in general — Decision 1 line); compositional clarity (type
identity vs. calling convention factor apart); future-proofing
(per-position metadata generalises; Type-variant approach
combinatoric blows up). The match-arm count remains parenthetical,
explicitly named a tiebreaker.

JOURNAL records the correction itself — the mistake stays as a
data point because how design discipline corrupts is informative.

CLAUDE.md

@@ -65,3 +65,52 @@ as immutable scripture.
   reason and a sub-agent would have to redo the same reading. In
   that case I do the small change inline and note in the JOURNAL
   why I bypassed the agent.
+
+### Design rationale ≠ implementation effort
+
+When picking between design options, the rationale must come from
+the language: semantics, structural fit, what the schema permits
+vs. forbids, compositional clarity, future-proofing. **Implementation
+effort is not a rationale.** "Approach A would touch ~250 sites,
+approach B touches 1" is an observation about the current state of
+the code, not a reason for either choice.
+
+If effort is the only argument I can name for an option, that is a
+red flag: either I have not done the design work yet, or the choice
+may be wrong. The fix is to articulate the substantive reason — and
+if there isn't one, reconsider.
+
+Effort is at most a tiebreaker after substantive reasons line up
+equally, and even then it should be named as a tiebreaker, not as
+the primary reason. The 18a "Type::Fn metadata vs. Type variant"
+call is the canonical anti-example: the right reason was semantic
+locality (modes belong to fn-parameter positions, not to types in
+general), and I retroactively had to add it. JOURNAL entries from
+2026-05-08 record the lesson.
+
+### Direction freedom
+
+I have authority to choose the next iter, refactor, or feature
+without asking. Wrong calls are recoverable: every commit is
+reachable via git, branches and tags exist for sharper rollback
+points (`pre-rc` is one such), and reverting one or several commits
+is cheap.
+
+The cost of asking "what should I do next" — context-switch for
+the user, latency on my side — exceeds the expected cost of an
+occasional rollback. So when the queue is non-empty and the path
+is clear, just pick and proceed.
+
+Bounce back to the user only when:
+
+- A queued option requires a real design judgement I have not
+  made myself (genuine architectural fork, multiple substantive
+  options none of which is clearly default).
+- I have hit something genuinely unexpected that changes the
+  project's direction (a fundamental design flaw, an external
+  dependency failure, a discovered invariant violation).
+- The user has explicitly asked for a checkpoint.
+
+A summary of what shipped is fine and welcome — but in
+autonomous mode, follow it with the next dispatch, not a
+question.