feat: Orbit v0.0.7 codebase (granular commits)

.claude/commands/changelog.md

@@ -0,0 +1,155 @@
+---
+description: Generate a marketing-quality changelog for a release version
+argument-hint: <version> [pr-number]
+allowed-tools: Bash(gh:*), Bash(git diff:*), Bash(git log:*), Bash(git branch:*), Bash(git status:*), Read, Write, Edit, Glob, Grep
+---
+
+# Changelog Generator
+
+Generate a changelog for Orbit release `$1`, written for the marketing site. If a PR number `$2` is provided, pull its metadata from GitHub.
+
+## Validation
+
+If `$1` is empty, output:
+
+```
+Usage: /changelog <version> [pr-number]
+Examples:
+  /changelog v0.0.7
+  /changelog v0.0.7 74
+```
+
+Stop execution.
+
+## Step 0: Resolve Version
+
+The version is `$1`. Determine whether it's a version or a PR number:
+
+- **Pure integer** (e.g., `73`, `104`) → This is a PR number, not a version. Infer the version from the current branch name and use `$1` as the PR number.
+- **Contains dots** (e.g., `0.0.7`, `v0.0.7`) → This is a version. Prepend `v` if missing.
+- **Starts with `v`** (e.g., `v0.0.7`) → This is a version. Use as-is.
+
+To get the branch name for fallback:
+
+```bash
+git branch --show-current
+```
+
+---
+
+## Step 1: Gather Context
+
+Collect all raw material. Run these commands:
+
+```bash
+git branch --show-current
+git log main..HEAD --oneline
+git diff main --stat
+git diff main --name-only
+git status --short
+```
+
+If a PR number is available (either `$2`, or `$1` if it was a bare number):
+
+```bash
+gh pr view <pr-number> --json title,body,commits,files
+```
+
+Check if a changelog already exists by reading `docs/changelog-<version>.md`. If it exists, you are **updating** — preserve existing content and add new entries. Do not rewrite what's already there.
+
+If the existing changelog already covers all committed and uncommitted changes, print `Changelog is up to date — nothing new to add.` and stop.
+
+Read `docs/changelog-v0.0.6.md` as the **tone and structure reference**. Match its style exactly.
+
+---
+
+## Step 2: Categorize Changes
+
+Group everything into user-facing categories. Use your judgment — not every commit deserves a section.
+
+| Category         | What goes here                                                            |
+| ---------------- | ------------------------------------------------------------------------- |
+| **New features** | Genuinely new capabilities a user would notice                            |
+| **Improvements** | Meaningful enhancements to existing features                              |
+| **Bug fixes**    | Things that were broken and are now fixed                                 |
+| **In-progress**  | Uncommitted or WIP work that's substantial enough to mention              |
+| **Internal**     | Only if genuinely interesting (new infra, major cleanup). Skip if boring. |
+
+**Discard:**
+
+- Routine refactors that don't change behavior
+- File renames, import reordering, lint fixes
+- Test additions (unless they represent a new testing capability)
+- Documentation changes (unless they're user-facing docs)
+
+---
+
+## Step 3: Write the Changelog
+
+Create or update `docs/changelog-<version>.md`.
+
+### Format
+
+```markdown
+# Orbit <version>
+
+_<Month Year>_
+
+---
+
+## <Category Name>
+
+### <Feature or improvement name>
+
+<1-2 paragraphs describing what the user gets. Not what files changed.>
+
+---
+
+## Bug Fixes
+
+- **<Short name>** — <What was broken, now fixed.>
+
+---
+
+## <Feature Name> _(in progress)_
+
+<One paragraph. What it will do. Note it ships in a later release.>
+
+---
+
+## Internal
+
+- <One-liner only>
+```
+
+### Writing Rules
+
+These are non-negotiable:
+
+1. **Lead with what users get.** "The branch picker now always shows search and branch creation" — not "Removed conditional Select/Popover logic."
+
+2. **No internal naming.** Never mention token names (`orbit-100`, `surface-primary`), store names (`useGitStore`), CSS variable names (`--color-border-subtle`), file paths, or function names.
+
+3. **No design system implementation details** unless the design system itself is the feature. "Consistent colors across light and dark themes" is fine. "Migrated from Radix 12-step scales to a 10-step primitive scale with three semantic layers" is not.
+
+4. **Don't elevate routine cleanup.** Removing dead code, fixing lint, updating dependencies — these are not features. If they're significant enough (e.g., 900+ lines of dead CSS removed), fold them into the relevant section as a supporting detail, not a headline.
+
+5. **Bug fixes are one-liners.** State what broke and that it's fixed. Don't explain the implementation.
+
+6. **In-progress features get one paragraph.** What it will do, what's built so far at a high level, and that it ships later.
+
+7. **Internal section uses one-liners.** If there's nothing interesting, omit the section entirely.
+
+8. **Don't sound impressed by your own work.** No "comprehensive", "robust", "elegant", "powerful". Just say what it does.
+
+9. **Match the reference.** Read `docs/changelog-v0.0.6.md` before writing. Your output should feel like the same person wrote both.
+
+---
+
+## Step 4: Output
+
+After writing the file:
+
+1. Print: `Changelog written to docs/changelog-<version>.md`
+2. Print the full changelog content
+3. If updating an existing file, note what was added

.claude/commands/implement.md

@@ -0,0 +1,188 @@
+---
+description: Implement a feature from an approved plan and spec sheet, phase by phase with AC verification
+argument-hint: <path-to-plan> <path-to-spec>
+allowed-tools: Read, Edit, Write, Glob, Grep, Bash, Agent, AskUserQuestion, LSP
+---
+
+# Feature Implementation
+
+You are a senior implementation engineer working in a production TypeScript/React/Rust/Tauri monorepo. You implement exactly what was planned and specified — no shortcuts, no gold-plating, no improvisation.
+
+<inputs>
+<plan_path>$1</plan_path>
+<spec_path>$2</spec_path>
+</inputs>
+
+If either path is empty, output the usage and stop:
+
+```
+Usage: /implement <path-to-plan> <path-to-spec>
+```
+
+---
+
+## Principles
+
+These govern every decision. When in doubt, return here.
+
+1. **Spec = WHAT.** Behavior, ACs, data contracts, error messages. If the spec doesn't address it, ask the user.
+2. **Plan = HOW.** Files, phases, architecture. Follow its structure.
+3. **Codebase wins conflicts.** When plan examples contradict actual codebase conventions, match the codebase.
+4. **ACs are contracts.** Never claim an AC passes without running the verification command.
+5. **No gold-plating.** If it's not in the plan or spec, don't build it.
+6. **Ask before guessing** on ambiguities that affect architecture or behavior.
+
+---
+
+## AC Status Definitions
+
+Use these consistently in phase reports and the final report:
+
+- **PASS**: Verified by running a command or test
+- **PENDING [Phase N]**: Cannot verify yet — depends on a later phase
+- **MANUAL**: Requires hardware, UI interaction, or manual testing
+- **PARTIAL**: Implemented but needs manual verification (explain what to check)
+- **BLOCKED**: Cannot verify without unavailable infrastructure (explain what's needed)
+- **MISSING**: Not implemented (explain why)
+
+---
+
+## Preparation (silent — do not output analysis or status)
+
+Read all of these before writing any code:
+
+1. **Plan** — extract phases, files, architecture, inter-phase dependencies
+2. **Spec** — extract ACs with priorities, data contracts, error taxonomy, constraints
+3. **Relevant CLAUDE.md files** — root + sub-level for every area you'll touch
+4. **Every existing file** the plan references — note actual signatures, types, patterns
+5. **Neighboring files** for every new file — learn local conventions, check barrel exports
+
+Then map which ACs become satisfiable after which plan phase.
+
+---
+
+## Execution
+
+### 1. Output the implementation sequence, then immediately start
+
+Do NOT wait for user confirmation. Output this once, then begin Phase 1:
+
+```
+## Implementation Sequence
+
+**Feature**: [name]
+**Phases**: [N] | **ACs**: [total] (P0: n, P1: n, P2: n, P3: n)
+
+Phase 1: [name] → [files] → ACs: [list]
+Phase 2: [name] → [files] → ACs: [list]
+...
+```
+
+### 2. Execute every plan phase continuously
+
+Work through every plan phase in order. Do NOT stop between phases to ask permission — just proceed. Only stop for genuine blockers you cannot resolve (spec ambiguity, missing section, compile error after two fix attempts).
+
+**For each plan phase:**
+
+**Announce:**
+
+```
+## Phase [N]: [Name]
+[files being created/modified] | ACs: [targeted]
+```
+
+**Before implementing**, identify which types, functions, or files from previous phases this phase depends on.
+
+**Implement** following all code quality rules from CLAUDE.md. Additionally:
+
+- New files: read a neighbor first for conventions; add to barrel exports (index.ts / mod.rs)
+- Modified files: re-read first (may have changed from earlier phases); make minimum changes
+- Use exact error message templates from the spec's Error Taxonomy
+- Match the spec's data contract types exactly
+
+**Validate:**
+
+1. Run `bun run typecheck` (if TypeScript changed) and/or `cargo check` (if Rust changed) — fix errors before continuing
+2. Run `bun run lint` if you created new files or made structural changes
+3. For each targeted AC: run the verification command if one exists. Never claim PASS from reading code alone when a command could verify it.
+
+**Report** (3-5 lines, then continue to next phase):
+
+<example>
+Phase 2 complete. Created: `src/hooks/browser/use-browser-nav.ts`. Modified: `src/hooks/browser/index.ts`, `src/stores/browser/browser-store.ts`.
+AC-4 (P0): PASS — `bun run typecheck` clean, hook returns `BrowserNavState`. AC-5 (P1): PASS — store triggers re-render (verified via test). AC-7 (P1): PENDING [Phase 4] — needs toolbar integration.
+Plan drift: Plan referenced `useBrowserStore.getState().activeTab` but store uses `.tabs.active`. Adapted to match codebase.
+</example>
+
+---
+
+## Final Validation
+
+After all plan phases complete:
+
+1. **Run full quality gates** — fix any failures:
+
+   ```
+   bun run check        # typecheck + lint + tests
+   cargo clippy         # if Rust touched
+   cargo test           # if Rust touched
+   ```
+
+2. **AC sweep** — walk every AC in the spec and assign a status (see AC Status Definitions above).
+
+3. **Output final report:**
+
+```
+## Implementation Complete
+
+**Feature**: [name] | **Branch**: [branch] | **Date**: [date]
+
+### Files Changed
+
+| File | Action | Phase |
+|------|--------|-------|
+| `path` | Created/Modified | Phase N |
+
+### Acceptance Criteria
+
+| AC | Pri | Status | Verification |
+|----|-----|--------|--------------|
+| AC-1 | P0 | PASS | `bun run typecheck` clean + test passes |
+
+**Summary**: [N]/[total] ACs satisfied. All P0s passing.
+
+### Quality Gates
+
+| Check | Status |
+|-------|--------|
+| TypeScript (`bun run typecheck`) | PASS/FAIL |
+| ESLint (`bun run lint`) | PASS/FAIL |
+| Frontend tests (`bun run test`) | PASS/FAIL |
+| Clippy (`cargo clippy`) | PASS/FAIL or N/A |
+| Rust tests (`cargo test`) | PASS/FAIL or N/A |
+
+### Issues & Deferred Items
+
+[Plan drift, skipped P3 items, observations worth noting]
+
+### Next Steps
+
+1. [e.g., manual verification for AC-12, AC-15]
+2. [e.g., run /audit-spec to verify spec accuracy]
+3. [e.g., create PR targeting main]
+```
+
+---
+
+## Error Recovery
+
+- **Compile errors**: Check actual codebase types, not what the plan assumed. Fix simply. Note drift in phase report.
+- **Plan drift**: File, function, or API doesn't exist where plan says? Search for the real location, adapt, note it.
+- **Ambiguity**: Check spec's Open Questions → neighboring code patterns → ask the user.
+- **Missing spec sections**: Flag the gap to the user. Do not fill it yourself.
+- **Scope creep**: Do not implement it. Note under "Observations" for the user to decide.
+- **Broken existing tests**: Fix them. Do not delete unless the plan explicitly says to.
+
+---
+
+Begin by reading the plan and spec documents.