Removing concrete technology mentions in story kit README, those living tech specs

.story_kit/README.md

@@ -119,7 +119,7 @@ When the user asks for a feature, follow this 4-step loop strictly:
 
 ### Step 3: The Implementation (Code)
 *   **Action:** Write the code to satisfy the approved tests and Acceptance Criteria.
-*   **Constraint:** adhere strictly to `specs/tech/STACK.md` (e.g., if it says "No `unwrap()`", you must not use `unwrap()`).
+*   **Constraint:** adhere strictly to `specs/tech/STACK.md` (e.g., if it forbids certain patterns, you must not use them).
 *   **Full-Stack Completion:** Every story must be completed across all components of the stack. If a feature touches the backend, frontend, and API layer, all three must be fully implemented and working end-to-end before the story can be accepted. Partial implementations (e.g., backend logic with no frontend wiring, or UI scaffolding with no real data) do not satisfy acceptance criteria.
 
 ### Step 4: Verification (Close)
@@ -165,7 +165,7 @@ Not everything needs to be a full story. Simple bugs can skip the story process:
     *   **Reproduction Steps:** How to trigger the bug
     *   **Proposed Fix:** Brief technical approach
     *   **Workaround:** Temporary solution if available
-2.  **Create a Worktree:** Create a git worktree and branch for the fix (e.g., `git worktree add ../project-bug-N -b bugfix/bug-N-description master`).
+2.  **Start an Agent:** Use the `start_agent` MCP tool to create a worktree and spawn an agent for the bug fix.
 3.  **Write a Failing Test:** Before fixing the bug, write a test that reproduces it (red). This proves the bug exists and prevents regression.
 4.  **Fix the Bug:** Make minimal code changes to make the test pass (green).
 5.  **User Testing:** Let the user verify the fix in the worktree before merging. Do not proceed until they confirm.
@@ -231,64 +231,12 @@ If a user hands you this document and says "Apply this process to my project":
 
 ---
 
-## 6. Code Quality Tools
+## 6. Code Quality
 
-**MANDATORY:** Before completing Step 4 (Verification) of any story, you MUST run all applicable linters and fix ALL errors and warnings. Zero tolerance for warnings or errors.
+**MANDATORY:** Before completing Step 4 (Verification) of any story, you MUST run all applicable linters, formatters, and test suites and fix ALL errors and warnings. Zero tolerance for warnings or errors.
 
 **AUTO-RUN CHECKS:** Always run the required lint/test/build checks as soon as relevant changes are made. Do not ask for permission to run them—run them automatically and fix any failures.
 
 **ALWAYS FIX DIAGNOSTICS:** At every stage, you must proactively fix all errors and warnings without waiting for user confirmation. Do not pause to ask whether to fix diagnostics—fix them immediately as part of the workflow.
 
-### TypeScript/JavaScript: Biome
+**Consult `specs/tech/STACK.md`** for the specific tools, commands, linter configurations, and quality gates for this project. The STACK file is the single source of truth for what must pass before a story can be accepted.
-
-*   **Tool:** [Biome](https://biomejs.dev/) - Fast formatter and linter
-*   **Check Command:** `npx @biomejs/biome check src/`
-*   **Fix Command:** `npx @biomejs/biome check --write src/`
-*   **Unsafe Fixes:** `npx @biomejs/biome check --write --unsafe src/`
-*   **Configuration:** `biome.json` in project root
-*   **When to Run:**
-    *   After every code change to TypeScript/React files
-    *   Before committing any frontend changes
-    *   During Step 4 (Verification) - must show 0 errors, 0 warnings
-
-**Biome Rules to Follow:**
-*   No `any` types (use proper TypeScript types or `unknown`)
-*   No array index as `key` in React (use stable IDs)
-*   No assignments in expressions (extract to separate statements)
-*   All buttons must have explicit `type` prop (`button`, `submit`, or `reset`)
-*   Mouse events must be accompanied by keyboard events for accessibility
-*   Use template literals instead of string concatenation
-*   Import types with `import type { }` syntax
-*   Organize imports automatically
-
-### Rust: Clippy
-
-*   **Tool:** [Clippy](https://github.com/rust-lang/rust-clippy) - Rust linter
-*   **Check Command:** `cargo clippy --all-targets --all-features`
-*   **Fix Command:** `cargo clippy --fix --allow-dirty --allow-staged`
-*   **When to Run:**
-    *   After every code change to Rust files
-    *   Before committing any backend changes
-    *   During Step 4 (Verification) - must show 0 errors, 0 warnings
-
-**Clippy Rules to Follow:**
-*   No unused variables (prefix with `_` if intentionally unused)
-*   No dead code (remove or mark with `#[allow(dead_code)]` if used conditionally)
-*   Use `?` operator instead of explicit error handling where possible
-*   Prefer `if let` over `match` for single-pattern matches
-*   Use meaningful variable names
-*   Follow Rust idioms and best practices
-
-### Build Verification Checklist
-
-Before asking for user acceptance in Step 4:
-
-- [ ] Run `cargo clippy` (Rust) - 0 errors, 0 warnings
-- [ ] Run `cargo check` (Rust) - successful compilation
-- [ ] Run `cargo test` (Rust) - all tests pass
-- [ ] Run `npx @biomejs/biome check src/` (TypeScript) - 0 errors, 0 warnings
-- [ ] Run `pnpm run build` (TypeScript) - successful build
-- [ ] Manually test the feature works as expected
-- [ ] All acceptance criteria verified
-
-**Failure to meet these criteria means the story is NOT ready for acceptance.**