v2.6.0 — Dashboard Elevated: boot sequence, ⌘K palette, tmux bar, mission track

.claude/commands/own/init.md

@@ -615,7 +615,7 @@ Update `.claude/ownyourcode-manifest.json` with profile settings:
 
 ```json
 {
-  "version": "2.5.0",
+  "version": "2.6.0",
   "installed_at": "...",
   "profile": {
     "type": "junior",
@@ -639,7 +639,7 @@ Update `.claude/ownyourcode-manifest.json` with profile settings:
 
 ```json
 {
-  "version": "2.5.0",
+  "version": "2.6.0",
   "installed_at": "...",
   "profile": {
     "type": "custom",
@@ -1221,7 +1221,7 @@ window.PROJECT = {
     audience: "[enum: myself | employers | clients | real-users]",
     mission:  "[the PROBLEM statement, in the user's words]",
     generated:"[today YYYY-MM-DD]",
-    version:  "2.5.0",
+    version:  "2.6.0",
   },
   dod: [
     { text: "[one concrete, measurable done-criterion]", done: false },
@@ -1254,7 +1254,7 @@ window.PROJECT = {
 | `meta.audience` | Phase 3 selection → enum: "Yourself"→`myself`, "Employers"→`employers`, "A client"→`clients`, "Real users"→`real-users` |
 | `meta.mission` | Phase 2 problem statement (the *why*, in their words) |
 | `meta.generated` | Today, `YYYY-MM-DD` |
-| `meta.version` | Literal `2.5.0` |
+| `meta.version` | Literal `2.6.0` |
 | `dod[]` | Phase 4 Definition-of-Done items, each `done:false` |
 | `stack[]` | Phase 5 stack + Phase 5.1 MCP-verified versions, as 5-tuples |
 | `phases[]` | Phase 5.5 collaborative roadmap — each `status:"roadmap-only"` with `items:[…]`, NO `spec`/`design`/`tasks` (those come from `/own:feature`) |

.claude/commands/own/theme.md

@@ -139,7 +139,8 @@ both `<script>` blocks (the data load + the render logic) — is UNTOUCHABLE.
 **The class contract is the current `<style>` itself.** Read the existing
 `<style>` block in `dashboard.html` to learn the complete set of selectors the
 render JS depends on (`.app`, `.hd`, `.sb`, `.nav`, `.tile`, `.bento`, `.kcard`,
-`.ring`, `.phase-numeral`, `.src`, `.bdg`, `.al-*`, etc.). The regenerated CSS
+`.ring`, `.phase-numeral`, `.src`, `.bdg`, `.al-*`, and the v2.6 additions:
+`.boot`/`.bline`, `.pal`, `.tmx`/`.seg`, `.tnode`/`.track`, `.burn`, `.segbar`, etc.). The regenerated CSS
 MUST style that exact same selector set — same class names, same structural
 roles — only the visual treatment changes per the brief.
 

.github/CLAUDE_REVIEWER.md

@@ -122,7 +122,7 @@ You are NOT a linter. You are a senior engineer mentoring a junior. This means:
 
 - **Explain the WHY.** Don't just say "missing plan-mode warning." Say: *"S3 violation — commands performing file operations need the plan-mode warning at the top (see `init.md` line 9). Without it, users in plan mode will get surprising behavior: skipped steps, half-finished operations, broken flow. The warning sets expectations and prevents support requests."*
 - **Reference the rule ID** (e.g., `P2`, `S3`, `T1`). The grouped prefix (P=Philosophy, S=Structure, T=Tooling, X=Security, D=Documentation) tells the contributor at a glance what kind of issue this is.
-- **Praise non-trivially good decisions.** If you see something *well-engineered* — a thoughtful profile-aware branch, a clean `.sh`/`.ps1` parity update, a teaching insight that genuinely deepens understanding, evidence-cited claims — call it out by name. Reinforcement shapes future contributions as much as correction does.
+- **Praise non-trivially good decisions.** If you see something *well-engineered* — a thoughtful profile-aware branch, a clean `.sh`/`.ps1` parity update, a teaching insight that genuinely deepens understanding, evidence-cited claims — call it out by name. Reinforcement shapes future contributions as much as correction does. **Hard cap: at most ONE praise comment per review, two sentences maximum.** Praise is a signal, not an essay — name the decision and why it's right, then stop.
 - **Suggest, don't dictate.** "Consider rephrasing this as a question to preserve Socratic Teaching" beats "rephrase as a question." Contributors need judgment, not obedience.
 - **Be direct but never harsh.** The code is wrong, the contributor is not. Critique the artifact, not the person.
 

.github/workflows/claude-review.yml

@@ -5,8 +5,11 @@ on:
     branches: [main]
     types: [opened, synchronize, reopened, ready_for_review]
 
+# Per-action groups so a push (incremental review) can never cancel an
+# in-flight full review of the PR opening — only runs of the same kind
+# supersede each other.
 concurrency:
-  group: claude-review-${{ github.event.pull_request.number }}
+  group: claude-review-${{ github.event.pull_request.number }}-${{ github.event.action }}
   cancel-in-progress: true
 
 jobs:
@@ -21,11 +24,18 @@ jobs:
       issues: write
       id-token: write
 
+    # Cost model: a FULL review (~$0.50-1.50) runs once, when the PR opens
+    # (or is reopened / marked ready). Each push ('synchronize') runs a much
+    # cheaper INCREMENTAL review (~$0.15-0.40): it reads the reviewer's own
+    # previous comments, diffs only the newly pushed commits
+    # (github.event.before..after), and reviews just that. For a fresh
+    # full-PR review on demand, mention @claude on the PR (claude-tag.yml).
     steps:
       - name: Checkout PR branch
         uses: actions/checkout@v6
         with:
-          fetch-depth: 1
+          # full history so incremental reviews can diff arbitrary push ranges
+          fetch-depth: 0
 
       - name: Load reviewer system prompt
         id: load_prompt
@@ -36,11 +46,11 @@ jobs:
             echo PROMPT_EOF
           } >> "$GITHUB_OUTPUT"
 
-      - name: Run Claude review
+      - name: Run Claude review (full — PR opened)
+        if: github.event.action != 'synchronize'
         uses: anthropics/claude-code-action@v1
         with:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
-          track_progress: true
           prompt: |
             REPO: ${{ github.repository }}
             PR NUMBER: ${{ github.event.pull_request.number }}
@@ -70,3 +80,55 @@ jobs:
 
           claude_args: |
             --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh pr checks:*),Read,Glob,Grep"
+            --max-turns 25
+
+      - name: Run Claude review (incremental — new commits only)
+        if: github.event.action == 'synchronize'
+        uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+            PR TITLE: ${{ github.event.pull_request.title }}
+            PR AUTHOR: ${{ github.event.pull_request.user.login }}
+            BASE BRANCH: ${{ github.event.pull_request.base.ref }}
+            HEAD BRANCH: ${{ github.event.pull_request.head.ref }}
+            NEWLY PUSHED RANGE: ${{ github.event.before }}..${{ github.event.after }}
+
+            ${{ steps.load_prompt.outputs.SYSTEM_PROMPT }}
+
+            ---
+
+            This is an INCREMENTAL review. You (a previous run of you) already
+            reviewed this PR in full when it opened. Do NOT re-review the whole PR.
+
+            Workflow for this review:
+            1. Read your previous feedback so you don't repeat or contradict it:
+               `gh pr view ${{ github.event.pull_request.number }} --comments` and
+               `gh api repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/comments`
+            2. See ONLY what this push changed:
+               `git diff ${{ github.event.before }}..${{ github.event.after }}`
+               (If that range fails — e.g. after a force-push — fall back to
+               `gh pr diff ${{ github.event.pull_request.number }}` and judge what's
+               new relative to your previous comments.)
+            3. Review ONLY the new diff against the standards. Where it addresses one
+               of your earlier findings, acknowledge that in a single line — don't
+               re-litigate what you already approved.
+            4. Scope exception: if the new commits touch contract- or security-critical
+               files (installers, templates, DASHBOARD_CONTRACT.md, workflows), you may
+               read surrounding context to judge cross-cutting impact.
+            5. Inline comments only for NEW findings. Then ONE short summary comment
+               (a few bullets max — this is a delta review, not a fresh report) via
+               `gh pr comment`, ending with the explicit verdict on its own line:
+               - `VERDICT: APPROVE` — ship it
+               - `VERDICT: REQUEST_CHANGES` — blocks merge, must be fixed
+               - `VERDICT: COMMENT` — observations only, no blocker
+            6. If the new diff is trivial (typo, docs wording, version string), say so
+               in at most two lines and give the verdict.
+
+            Do not submit review text as chat messages — only as GitHub comments.
+
+          claude_args: |
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh pr checks:*),Bash(gh api repos/*/pulls/*/comments*),Bash(git diff:*),Bash(git log:*),Read,Glob,Grep"
+            --max-turns 15