opencastle 0.32.4 → 0.32.6

package/src/orchestrator/plugins/teams/SKILL.md

@@ -26,26 +26,14 @@ Agent communication patterns via the Microsoft Teams MCP server (Microsoft Agent
 3. **Graph API permissions:** `McpServers.Teams.All` (delegated or application)
 4. **Admin consent** for the registered app
 
-> **Note:** The Teams MCP server is in preview and not yet generally available as a standalone endpoint. Features and availability may change.
-
 ## Available MCP Tools
 
-The Teams MCP server exposes tools for:
-
-- **Chats** — Create, list, read, update, delete chats
-- **Messages** — Send, read, edit, delete messages in chats and channels
-- **Channels** — List, create, manage channel settings
-- **Members** — List, add, remove members from chats and channels
-- **Teams** — List teams, get team details, manage team settings
-
-Tool names follow the pattern `teams_<resource>_<action>`. Use tool discovery to list available tools at runtime.
+Tool names follow `teams_<resource>_<action>`. Covers: chats, messages, channels, members, and team settings. Use tool discovery to list available tools at runtime.
 
 ## Agent Notification Patterns
 
 ### Progress Updates
 
-Post structured progress updates to a designated channel:
-
 ```
 Channel: Agent Updates (or project-specific channel)
 Format:
@@ -55,52 +43,21 @@ Format:
   **ETA:** ~5 minutes
 ```
 
-### Completion Notifications
-
-```
-✅ **Task:** TAS-42 — Add price filter component
-**Status:** Complete — PR opened
-**PR:** https://github.com/org/repo/pull/123
-**Summary:** Added PriceRangeFilter with 4 range options, 12 unit tests passing
-```
-
-### Error / Blocking Notifications
-
-```
-🚨 **Task:** TAS-42 — Add price filter component
-**Status:** Blocked — needs human input
-**Issue:** Cannot determine correct price ranges for the market
-**Action needed:** Reply in this thread with the desired price range values
-```
+## Human-in-the-Loop Approval
 
-## Bi-Directional Communication
-
-### Human-in-the-Loop Approval
-
-When an agent needs approval before proceeding:
-
-1. **Post approval request** to the channel with clear instructions:
+1. **Post approval request** to the channel:
    ```
    ⏳ **Approval Required**
    Task: TAS-42 — Database migration adds `price_range` column
    Action: Run migration on production database
-   
+
    Reply with:
    ✅ Approve — to proceed
    ❌ Reject — to stop
    Or reply with questions/comments
    ```
-
-2. **Poll for response** — Read replies to determine the decision
-3. **Acknowledge** — Post confirmation of the action taken
-
-### Reading User Responses
-
-To check for approvals or instructions:
-
-1. Read message replies in the channel or chat thread
-2. Parse reply content for approval keywords (`approve`, `approved`, `yes`, `proceed`, `reject`, `no`, `stop`)
-3. Check for reactions on messages (Teams supports reactions via Graph API)
+2. **Poll for response** — Read replies to determine the decision.
+3. **Acknowledge** — Post confirmation of the action taken.
 
 ### Parsing Conventions
 
@@ -114,15 +71,6 @@ To check for approvals or instructions:
 
 ## Channel & Chat Conventions
 
-### Channel Structure
-
-| Channel | Purpose |
-|---------|---------|
-| Agent Updates | General agent activity feed |
-| Agent Approvals | Approval requests requiring human action |
-| Agent Errors | Error reports and blocked tasks |
-| Project-specific channel | All activity for a specific project |
-
 ### Threading Rules
 
 - **Always reply in threads** — use message replies, not top-level posts for follow-ups
@@ -130,33 +78,11 @@ To check for approvals or instructions:
 - **Include task ID** — every message references the tracker issue ID
 - **Mark important messages** — use importance flags for approval requests
 
-### Chat vs Channel
-
-| Use Case | Preferred |
-|----------|-----------|
-| Team-wide updates | Channel |
-| Approval requests | Channel (for visibility) |
-| Direct questions | 1:1 or group chat |
-| Sensitive discussions | 1:1 chat |
-
 ## Message Formatting
 
-Teams messages support HTML and a subset of Markdown:
-
-| Format | Syntax |
-|--------|--------|
-| Bold | `**bold**` or `<strong>bold</strong>` |
-| Italic | `*italic*` or `<em>italic</em>` |
-| Code | `` `inline code` `` |
-| Code block | ` ```code block``` ` |
-| Link | `[Display Text](https://example.com)` |
-| User mention | `<at>User Name</at>` (requires user ID in adaptive card) |
-| List | `- item` or `1. item` |
-| Heading | `### Heading` |
-
 ### Adaptive Cards
 
-For richer formatting, Teams supports Adaptive Cards (JSON-based card format):
+For richer formatting, use Adaptive Cards (JSON-based):
 
 ```json
 {
@@ -178,74 +104,18 @@ Use Adaptive Cards for approval workflows when available — they provide struct
 
 ## Rate Limits
 
-Microsoft Graph API rate limits for Teams:
-
-| Resource | Limit |
-|----------|-------|
-| Messages (per app per tenant) | 50 per second |
-| Channel messages | 50 per second |
-| Chat creation | 50 per second |
-| Individual API calls | 10,000 per 10 minutes |
+Microsoft Graph API: 50 messages/second per app per tenant; 10,000 individual API calls per 10 minutes.
 
 **Best practices:**
 - Batch updates into single messages rather than posting many small messages
-- Use threads to consolidate related updates
 - Cache team/channel/user IDs — don't look them up repeatedly
-- Respect 429 (Too Many Requests) responses with retry-after headers
 
 ## Security Considerations
 
 - **OAuth tokens** are managed by the MCP server — agents never see raw tokens
 - **Scope minimization** — request only the Graph API permissions agents actually need
-- **Tenant restrictions** — configure the app for single-tenant or specific tenant access
-- **Conditional Access** — Microsoft Entra Conditional Access policies apply to API calls
-- **Audit logging** — Microsoft 365 audit logs capture all Graph API activity
-- **No secrets in messages** — never post tokens, passwords, or credentials in Teams messages (per Constitution #1)
-- **Data residency** — Teams data is stored in the tenant's Microsoft 365 region
-
-## Integration with Agent Workflows
-
-### Session Start
-
-At the beginning of a work session, post a brief status message:
-```
-🏁 **Session started**
-Agent: Frontend Engineer
-Task: TAS-42 — Add price filter component
-Mode: Autonomous (will request approval for destructive actions)
-```
-
-### Session End
-
-At the end of a work session, post a summary:
-```
-🏁 **Session complete**
-Agent: Frontend Engineer
-Task: TAS-42 — Add price filter component
-Result: ✅ PR opened (#123)
-Duration: 12 minutes
-Files changed: 5
-Tests: 12 passing, 0 failing
-```
-
-### Error Recovery
-
-If an agent encounters an unrecoverable error, notify before stopping:
-```
-💥 **Session failed**
-Agent: Frontend Engineer
-Task: TAS-42 — Add price filter component
-Error: TypeScript compilation failed — 3 type errors in PriceFilter.tsx
-Action: Posted details in thread. Needs manual fix or re-delegation.
-```
+- **No secrets in messages** — never post tokens, passwords, or credentials in Teams messages
 
 ## Preview Limitations
 
-Since the Teams MCP server is in Frontier preview:
-
-- **Availability** may change without notice
-- **Tool surface** may be incomplete compared to the full Graph API
-- **Performance** may vary during preview
-- **Breaking changes** are possible between preview versions
-
-Check [Microsoft Agent 365 documentation](https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/) for the latest status.
+The Teams MCP server is in Frontier preview — availability and tool surface may change without notice. Check [Microsoft Agent 365 documentation](https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/) for the latest status.

package/src/orchestrator/plugins/trello/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: trello-task-management
+description: "Trello board conventions for tracking feature work — board/list/card workflow, checklist-driven task breakdown, due dates, and when to use comments vs checklist items. Use when decomposing features into cards or resuming interrupted sessions."
+---
+
+<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .opencastle/ directory instead. -->
+
+# Task Management with Trello
+
+Conventions for tracking feature work on Trello boards via MCP tools. For project-specific board IDs and list IDs, see [tracker-config.md](../../.opencastle/project/tracker-config.md).
+
+## MCP Server
+
+| Field | Value |
+|-------|-------|
+| **Package** | [`@delorenj/mcp-server-trello`](https://www.npmjs.com/package/@delorenj/mcp-server-trello) |
+| **Type** | stdio (spawned via `npx -y @delorenj/mcp-server-trello`) |
+| **Auth** | API key + token via `TRELLO_API_KEY` and `TRELLO_TOKEN` env vars |
+
+### Authentication
+
+1. Get your API key at [trello.com/app-key](https://trello.com/app-key) → **API Key**
+2. On the same page, click **"Generate a Token"** to get your token
+3. Add both to your `.env` file:
+
+```
+TRELLO_API_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+TRELLO_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+```
+
+## Available MCP Tools
+
+| Tool | Description |
+|------|-------------|
+| `get_boards` | List all boards accessible to the authenticated user |
+| `get_lists` | Get all lists on a board (by board ID) |
+| `get_cards_by_list_id` | Get all cards in a specific list |
+| `get_card_details` | Get full details of a single card |
+| `create_card` | Create a new card in a list |
+| `update_card` | Update card fields (name, description, due date, list) |
+| `add_checklist_to_card` | Add a checklist with items to a card |
+| `add_comment_to_card` | Post a comment on a card |
+
+## Discovered Issues (Bug Tickets)
+
+When an agent encounters a pre-existing bug or issue unrelated to the current task, it must be tracked:
+
+1. **Check** existing cards on the board to see if it is already tracked
+2. **If tracked** — skip it, continue with current work
+3. **If NOT tracked:**
+   - **Unfixable limitation** — add to known issues with severity, evidence, and root cause
+   - **Fixable bug** — create a Trello card:
+     - **Name:** `[Bug] Short description of the symptom`
+     - **List:** `Backlog` (or the equivalent list in your project)
+     - **Description:** Include symptoms, reproduction steps, affected files, and any error messages
+     - **Due date:** Set only if it is blocking current work
+
+## Card Naming
+
+Use `[Area] Short description` format:
+
+```
+[Schema] Add priceRange field to place type
+[DB] Add price_range column and migration
+[UI] Build PriceRangeFilter component
+[API] Add price filter endpoint
+[Test] Unit tests for price filter
+[Docs] Update data model documentation
+```
+
+**Area prefixes:** `[Schema]`, `[DB]`, `[Query]`, `[UI]`, `[Page]`, `[API]`, `[Auth]`, `[Test]`, `[Docs]`, `[Deploy]`, `[Data]`, `[Perf]`, `[Security]`, `[Bug]`
+
+## Board and List Workflow
+
+### Typical List Structure
+
+```
+Backlog  →  To Do  →  In Progress  →  In Review  →  Done
+```
+
+- **Backlog** — Captured but not yet planned
+- **To Do** — Planned and ready to start
+- **In Progress** — Actively being worked on
+- **In Review** — PR open, awaiting review or merge
+- **Done** — Completed and verified
+
+### Agent-Driven Card Transitions (via MCP)
+
+| From | To | When |
+|------|----|------|
+| Backlog / To Do | In Progress | Agent starts working on the card |
+| In Progress | Done | Non-PR task is verified (docs, config) |
+| Any | Backlog | Task is deferred |
+
+## Checklist-Driven Task Breakdown
+
+Use checklists for **subtask decomposition within a single card**. This keeps related work together without cluttering the board with micro-cards.
+
+### When to Use a Checklist vs a Separate Card
+
+| Use a **checklist item** when… | Use a **separate card** when… |
+|-------------------------------|------------------------------|
+| Steps are sequential and tightly coupled | Work can be assigned independently |
+| Total effort fits in one session | Each step spans multiple sessions |
+| Steps share the same assignee | Steps need different labels/due dates |
+| Internal implementation details | Distinct deliverables that need review |
+
+### Checklist Pattern for Feature Decomposition
+
+```
+Card: [Feature] Add price range filter
+Checklist: Implementation Steps
+  ☐ Add priceRange field to schema
+  ☐ Create DB migration
+  ☐ Update GROQ/API query
+  ☐ Build UI component
+  ☐ Wire into page
+  ☐ Write unit tests
+  ☐ Update documentation
+```
+
+## Due and Start Dates
+
+Trello cards support both a **start date** and a **due date**.
+
+- **Due date** — The deadline for the card to move to Done. Set for tasks on the critical path.
+- **Start date** — When work is expected to begin. Useful for pipeline planning.
+- **Due time** — Be explicit with time only for time-sensitive deliverables (e.g., scheduled releases).
+- **Format:** Trello API uses ISO 8601: `2026-03-20T14:00:00.000Z`
+
+## Comments vs Checklist Items
+
+| Use **comments** for… | Use **checklist items** for… |
+|-----------------------|------------------------------|
+| Progress updates visible to the team | Actionable steps with completion state |
+| Blocking issues or decisions | Pre-defined subtask decomposition |
+| Links to PRs, builds, external docs | Typed acceptance criteria |
+| Questions or async approvals | Implementation sub-steps |
+| Post-implementation notes | QA verification steps |
+
+**Rule of thumb:** If it needs to be *checked off*, it's a checklist item. If it needs to be *read*, it's a comment.
+
+## Session Continuity
+
+At the start of each work session:
+
+1. `get_boards` — confirm the right board is active
+2. `get_lists` — identify current list structure
+3. `get_cards_by_list_id` for **In Progress** — find cards already in flight
+4. Resume work on the relevant card, updating the checklist as steps complete
+5. Move the card to the next list when the current phase is done

package/src/orchestrator/plugins/trello/config.ts

@@ -0,0 +1,44 @@
+import type { PluginConfig } from '../types.js';
+
+export const config: PluginConfig = {
+  id: 'trello',
+  name: 'Trello',
+  category: 'team',
+  subCategory: 'task-management',
+  label: 'Trello',
+  hint: 'Visual board task management via MCP',
+  skillName: 'trello-task-management',
+  mcpServerKey: 'Trello',
+  mcpConfig: {
+    type: 'stdio',
+    command: 'npx',
+    args: ['-y', '@delorenj/mcp-server-trello'],
+    envFile: '${workspaceFolder}/.env',
+  },
+  authType: 'env-token',
+  envVars: [
+    {
+      name: 'TRELLO_API_KEY',
+      hint: 'Create at trello.com/app-key -> API Key',
+    },
+    {
+      name: 'TRELLO_TOKEN',
+      hint: 'Generate at trello.com/app-key -> Token (click "Generate a Token")',
+    },
+  ],
+  agentToolMap: {
+    'team-lead': [
+      'Trello/get_boards',
+      'Trello/get_lists',
+      'Trello/get_cards_by_list_id',
+      'Trello/get_card_details',
+      'Trello/create_card',
+      'Trello/update_card',
+      'Trello/add_checklist_to_card',
+      'Trello/add_comment_to_card',
+    ],
+  },
+  docsUrl: 'https://www.opencastle.dev/docs/plugins#trello',
+  officialDocs: 'https://developer.atlassian.com/cloud/trello/',
+  mcpPackage: '@delorenj/mcp-server-trello',
+};

package/src/orchestrator/plugins/types.ts

@@ -13,7 +13,7 @@ export interface PluginConfig {
   category: 'tech' | 'team';
 
   /** Sub-category for grouping */
-  subCategory: 'cms' | 'database' | 'deployment' | 'framework' | 'codebase-tool' | 'task-management' | 'notifications' | 'testing' | 'e2e-testing' | 'design' | 'email';
+  subCategory: 'cms' | 'database' | 'deployment' | 'framework' | 'codebase-tool' | 'task-management' | 'knowledge-management' | 'notifications' | 'testing' | 'e2e-testing' | 'design' | 'email';
 
   /** Label shown in the `npx opencastle init` multiselect */
   label: string;

package/src/orchestrator/plugins/vitest/SKILL.md

@@ -158,9 +158,9 @@ export default defineConfig({
 - Use `describe` blocks to group related tests
 - Each test should be independent — no shared mutable state between tests
 - Clean up mocks with `vi.restoreAllMocks()` in `afterEach`
-- Use `vi.mock()` at the top level — Vitest hoists mock calls automatically
+- Mock dependencies before imports — `vi.mock()` calls are hoisted automatically but declare them at the top for clarity
 - Prefer `toEqual` for objects, `toBe` for primitives
 - Use `test.each` for parameterized tests
 - Set coverage thresholds to prevent regression
 - Use `vi.useFakeTimers()` for time-dependent code — never `setTimeout` in tests
-- Use `--reporter=json` in CI for machine-readable output
+- Aim for 3-5 focused tests per file for maintainability — split large test suites

package/src/orchestrator/prompts/bug-fix.prompt.md

@@ -15,8 +15,6 @@ You are the Team Lead. Investigate and fix the bug described below. Bugs are rea
 
 ---
 
-> **Canonical workflow:** `.github/agent-workflows/bug-fix.md` defines the phase structure. This prompt expands each phase with delegation-specific detail. If the two diverge, update the workflow first (SSOT) then sync the prompt.
-
 ## How Bug Fixes Differ from Other Workflows
 
 | Aspect | Roadmap Task | Follow-Up | Bug Fix |
@@ -33,52 +31,27 @@ You are the Team Lead. Investigate and fix the bug described below. Bugs are rea
 
 ### 1. Triage & Reproduce
 
-Before fixing anything, understand the bug:
-
 1. **Check known issues** — Search `.opencastle/KNOWN-ISSUES.md` for an existing entry. If found, note workarounds and decide if a fix is now feasible
 2. **Check tracker** — Search for existing bug tickets. If one exists, take it over instead of creating a duplicate
 3. **Read lessons learned** — Check `.opencastle/LESSONS-LEARNED.md` for related pitfalls
-4. **Reproduce the bug** — Start the dev server and confirm you can trigger the issue:
-   - Start the dev server (see the **codebase-tool** skill for the serve command)
-   - Navigate to the affected page in Chrome
-   - Follow the reproduction steps from the bug report
-   - Take a screenshot of the broken state as evidence
+4. **Reproduce the bug** — Start the dev server (see **codebase-tool** skill), navigate to the affected page in Chrome, follow the repro steps, and screenshot the broken state
 5. **Determine scope** — Which apps are affected? (see `project.instructions.md` for the app inventory)
-6. **Assess severity**:
-   - **Critical** — App crashes, data loss, auth bypass, page won't load
-   - **High** — Feature broken but workaround exists, significant UI breakage
-   - **Medium** — Minor functional issue, cosmetic but noticeable
-   - **Low** — Edge case, minor visual glitch
+6. **Assess severity**: Critical (crash/data loss/auth bypass) | High (broken + workaround) | Medium (minor functional) | Low (edge case/cosmetic)
 
 ### 2. Create Tracker Issue
 
 Every bug gets tracked. Create a tracker issue with:
 
 - **Title**: `[Bug] Short description of the symptom`
-- **Label**: `bug`
-- **Priority**: Based on severity assessment above
-- **Description**:
-  - **Symptom**: What the user sees
-  - **Reproduction steps**: Exact steps to trigger
-  - **Expected behavior**: What should happen
-  - **Actual behavior**: What happens instead
-  - **Affected apps**: which apps from the project inventory
-  - **Affected files** (once identified): File paths for the partition
-  - **Screenshot**: Link or description of the broken state
+- **Label**: `bug`; **Priority**: based on severity
+- **Description**: Symptom, reproduction steps, expected vs actual behavior, affected apps + files, screenshot
 
 ### 3. Root Cause Analysis
 
-Find WHY the bug happens, not just WHERE:
-
 1. **Search the codebase** — Find the components, queries, styles, and logic involved
-2. **Trace the data flow** — Follow the data from source (CMS/database) → query → component → render
-3. **Check recent changes** — Use `git log` on suspected files to see if a recent commit introduced the issue
-4. **Identify the root cause** — Distinguish between:
-   - **Code bug** — Logic error, wrong condition, missing null check
-   - **Data issue** — Unexpected data shape, missing field, bad reference
-   - **Race condition** — Timing issue, hydration mismatch, async ordering
-   - **CSS/Layout** — Specificity conflict, missing responsive rule, overflow
-   - **Integration** — API contract mismatch, schema drift, stale cache
+2. **Trace the data flow** — Source (CMS/database) → query → component → render
+3. **Check recent changes** — `git log` on suspected files
+4. **Identify the root cause** — Code bug, Data issue, Race condition, CSS/Layout, or Integration failure
 5. **Update the tracker issue** — Add root cause findings and affected file paths
 
 ### 4. Implement the Fix
@@ -91,37 +64,29 @@ All bug fixes are executed via the convoy engine — even single-task fixes —
 
 #### Convoy Task Prompt Must Include
 
-- **Tracker issue ID and title** — e.g., `TAS-XX — [Bug] Description`
-- **Root cause** — What's wrong and why
-- **Fix approach** — How to fix it (be specific)
-- **File paths** — Exact files to read and modify
-- **Reproduction steps** — So the agent can verify the fix
-- **Boundaries** — "Only modify files listed above. Fix the bug, do not refactor surrounding code."
-- **Self-improvement reminder** — include per the **self-improvement** skill
+- Tracker issue ID and title, root cause, fix approach, file paths, reproduction steps
+- Boundaries: "Only modify files listed above. Fix the bug, do not refactor surrounding code."
+- Self-improvement reminder (see **self-improvement** skill)
 
 #### Implementation Rules
 
-- **Minimal change** — Fix the bug with the smallest correct change. Resist the urge to refactor
-- **Fix the cause, not the symptom** — A CSS `!important` or silent `catch {}` is not a fix
-- **DRY** — If the fix involves logic that exists elsewhere, reuse it
-- **Add a test** — If no test covers this scenario, add one. Bugs that aren't tested come back
-- **Cross-app awareness** — If the fix is in shared code (`libs/`), verify it works for both apps
+- **Fix cause not symptom** — Minimal change, no refactoring. A CSS `!important` or silent `catch {}` is not a fix
+- **Add a test** — If no test covers this scenario, add one
+- **Cross-app awareness** — If the fix is in `libs/`, verify it works in all consuming apps
 
 ### 5. Validate
 
 > Load the **validation-gates** skill for detailed steps on each gate.
 
-Every bug fix must pass ALL applicable gates:
-
-1. **Gate 1: Secret Scanning** — scan diff for API keys, tokens, passwords, connection strings — block immediately if found
-2. **Gate 2: Deterministic Checks** — run lint, test, and build for all affected projects (see the **codebase-tool** skill for commands) — all zero errors
-3. **Gate 3: Blast Radius Check** — verify the fix is minimal and scoped (bug fixes should be ≤100 lines, ≤3 files; escalate if larger)
-4. **Gate 4: Dependency Audit** (when `package.json` or lockfiles change) — vulnerability scan, license check, bundle size, duplicates
-5. **Gate 5: Fast Review** (MANDATORY) — single reviewer sub-agent validates the fix. No auto-PASS for sensitive files
-6. **Gate 6: Bug-Specific Verification** (MANDATORY) — start dev server, reproduce original bug (should be gone), verify correct behavior, test edge cases, screenshot before/after, check both apps if shared code
-7. **Gate 7: Browser Testing** (for UI-related bugs) — clear cache, start server, verify fix + responsive + screenshots
-8. **Gate 8: Regression Testing** — run tests for all projects consuming modified files, browser-test adjacent functionality
-9. **Gate 9: Panel Review** (only if needed) — use **panel-majority-vote** skill if fix touches auth/authorization, RLS, security headers/CSP, or sensitive data
+1. **Secret Scanning** — block if API keys/tokens/passwords found in diff
+2. **Deterministic Checks** — lint, test, build — zero errors (see **codebase-tool** skill)
+3. **Blast Radius** — bug fixes should be ≤100 lines / ≤3 files; escalate if larger
+4. **Dependency Audit** — when `package.json` or lockfiles change
+5. **Fast Review** (MANDATORY) — single reviewer sub-agent
+6. **Bug-Specific Verification** (MANDATORY) — reproduce original bug (should be gone), verify correct behavior, screenshot before/after, check both apps if shared code
+7. **Browser Testing** (for UI bugs) — clear cache, verify fix + responsive + screenshots
+8. **Regression Testing** — run tests for all projects consuming modified files
+9. **Panel Review** — only if fix touches auth/authorization, RLS, security headers, or sensitive data (use **panel-majority-vote** skill)
 
 ### 6. Delivery
 
@@ -129,10 +94,9 @@ Follow the **Delivery Outcome** defined in the **git-workflow** skill — commit
 
 ### 7. Wrap Up
 
-1. **Move tracker issue to Done** — Only after all validation passes
-2. **Update Known Issues** — If this was a documented known issue, remove or update the entry in `.opencastle/KNOWN-ISSUES.md`
-3. **Capture lessons** — If the root cause reveals a pattern that other agents should know about, use the **self-improvement** skill to add a lesson
-4. **Note prevention** — If this class of bug could be caught earlier (by a lint rule, test, or type check), note that in the tracker issue as a follow-up suggestion
+1. **Close out** — Move tracker to Done; remove or update any `.opencastle/KNOWN-ISSUES.md` entry if applicable
+2. **Capture lessons** — Use the **self-improvement** skill if the root cause reveals a pattern others should know
+3. **Note prevention** — If the bug class could be caught earlier, note it in the tracker as a follow-up
 
 ### 8. Completion Criteria
 
@@ -142,9 +106,7 @@ The bug fix is complete when:
 - [ ] Tracker issue created with full details
 - [ ] Fix implemented with minimal change
 - [ ] Test added covering the bug scenario
-- [ ] Lint, test, and build pass for all affected projects
 - [ ] Bug verified fixed in the browser
-- [ ] No regressions in adjacent functionality
 - [ ] Both apps checked if shared code was modified
 - [ ] Delivery Outcome completed (see the **git-workflow** skill) — branch pushed, PR opened (not merged), tracker linked
 - [ ] Tracker issue moved to Done