Tighten the output rules and make committing unconditional

Two standing instructions from the user, encoded so they survive the
session:

- OUTPUTS: default reply is 1-5 lines, answer on the first line. An
  important or security-related finding is not licence to expand — it
  gets a blunter line, not a longer one. A finding that gets skipped is
  a finding that does not exist.
- Always commit finished work once the gates are green, rather than
  leaving it pending review. Push and PRs still require an explicit ask.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PngVF38MLpdkgXcByKfdW6

CLAUDE.md

@@ -173,6 +173,7 @@ Binding for all work here, not just verification.
 * **Post-edit verification:** check immediately for duplicated lines and intact imports.
 * **Stability check:** after any change, run that side's lint + typecheck + tests. For cross-cutting changes (e.g. API contract edits in `app/models` and `src/types`), run **both** suites — they must agree on the wire format.
 * **Keep the graph current:** `graphify update .` after code changes.
+* **Always commit:** commit finished work without being asked — this overrides any default to wait for permission. Commit once the gates are green, never mid-change or over a failing suite. **Push and PRs still require an explicit ask.** Never commit on the default branch; branch first.
 
 ---
 
@@ -200,4 +201,15 @@ Unsure about a rule? Ask before encoding a number — Swedish rules change, and
 
 ## OUTPUTS
 
-Be concise: no preamble, caveats, or restating the request. Sentence fragments and short bullets where clarity holds. Explain reasoning only when it aids debugging or isn't obvious from the code/diff.
+**Default reply: 1-5 lines.** Bullets or a small table. No preamble, no recap, no restating the request.
+
+Hard rules:
+* Lead with the answer. A yes/no question gets yes or no on line one.
+* One line per finding. Name it, say it's fixed, move on.
+* Never re-narrate a subagent report or a diff — extract the decision, drop the rest.
+* Never explain reasoning that wasn't asked for, and never justify a choice in more than one clause.
+* No "want me to X?" when X is obvious.
+
+Length is **not** licensed by a finding being important, security-related, or surprising. An important finding gets a short, blunt line — that is what makes it get read. The only things that may run long: raw failure output, and an open product trade-off that needs a decision.
+
+Explain reasoning only when it aids debugging or isn't obvious from the code/diff.