super-opencode 1.1.2 → 1.2.0

package/.opencode/skills/reflexion/SKILL.md

@@ -6,12 +6,14 @@ description: Post-action analysis to generate heuristics, update project memory,
 # Reflexion Skill
 
 ## Purpose
+
 To transform **Failures** into **Heuristics**.
 Reflexion is the cognitive step that occurs **after** a failed attempt and **before** the next attempt. It breaks the "Insanity Loop" (doing the same thing twice expecting different results).
 
 **ROI Metric**: Prevents 5-10 wasted attempts in a loop by forcing a strategy shift after the first failure.
 
 ## When to Use
+
 - **Automatic Trigger**: After a tool error (e.g., `bash` exit code != 0).
 - **Automatic Trigger**: After a test failure during `execution` mode.
 - **Manual Trigger**: When the user rejects an artifact ("This isn't what I asked for").
@@ -20,24 +22,28 @@ Reflexion is the cognitive step that occurs **after** a failed attempt and **bef
 ## The Reflexion Protocol (The Loop)
 
 ### 1. The Halt (Stop)
+
 **Rule**: *Never retry immediately.*
 If an error occurs, you must pause. Do not simply re-run the command hoping for a different outcome.
 
 ### 2. The Trace (Diagnosis)
+
 **Action**: Analyze the mismatch between *Expected Output* and *Actual Output*.
-*   *Was it a Syntax Error?* (Context failure).
-*   *Was it a Logic Error?* (Reasoning failure).
-*   *Was it a Hallucination?* (Knowledge failure).
+- *Was it a Syntax Error?* (Context failure).
+- *Was it a Logic Error?* (Reasoning failure).
+- *Was it a Hallucination?* (Knowledge failure).
 
 ### 3. The Heuristic (Correction)
+
 **Action**: Create a new rule for yourself.
-*   *Old Thought:* "I will use `rm -rf` to clean up."
-*   *New Heuristic:* "I must check if the directory exists before attempting delete."
+- *Old Thought:* "I will use `rm -rf` to clean up."
+- *New Heuristic:* "I must check if the directory exists before attempting delete."
 
 ### 4. The Store (Memory)
+
 **Action**: Save this lesson.
-*   *Short-term:* Apply to current context window.
-*   *Long-term:* Write to `.opencode/memory/patterns.md`.
+- *Short-term:* Apply to current context window.
+- *Long-term:* Write to `.opencode/memory/patterns.md`.
 
 ## Execution Template
 
@@ -77,6 +83,7 @@ Maintain a dedicated memory structure to allow the `researcher` and `pm-agent` t
 ```
 
 ### Example: `.opencode/memory/anti_patterns.md`
+
 ```markdown
 ## ⛔ Anti-Patterns
 
@@ -93,10 +100,10 @@ Maintain a dedicated memory structure to allow the `researcher` and `pm-agent` t
 
 ## Integration with Agents
 
--   **`execution` agent**: Must trigger `reflexion` after 2 failed build attempts.
-    -   *Logic:* "Attempt 1 Failed -> Retry -> Attempt 2 Failed -> **STOP & REFLECT** -> Attempt 3".
--   **`pm-agent`**: Reads `.opencode/memory/patterns.md` at the start of a new task to load context.
--   **`writer`**: Uses successful reflexions to update the project's `README.md` or `CONTRIBUTING.md`.
+- **`execution` agent**: Must trigger `reflexion` after 2 failed build attempts.
+  - *Logic:* "Attempt 1 Failed -> Retry -> Attempt 2 Failed -> **STOP & REFLECT** -> Attempt 3".
+- **`pm-agent`**: Reads `.opencode/memory/patterns.md` at the start of a new task to load context.
+- **`writer`**: Uses successful reflexions to update the project's `README.md` or `CONTRIBUTING.md`.
 
 ## Reflexion vs. Debugging
 

package/.opencode/skills/security-audit/SKILL.md

@@ -6,20 +6,23 @@ description: Static Analysis and Threat Modeling skill to detect OWASP Top 10 vu
 # Security Audit Skill
 
 ## Purpose
+
 To act as an automated **SAST (Static Application Security Testing)** scanner.
 **Goal**: Identify vulnerabilities in the *implementation* phase, before the code reaches the `review` phase.
 
 **ROI Metric**: Detecting a hardcoded secret here takes 5 seconds. Rotating a compromised key in production takes 5 hours.
 
 ## When to Use
--   **Trigger**: When `backend` implements an endpoint involving `users`, `auth`, or `payments`.
--   **Trigger**: When `frontend` uses `dangerouslySetInnerHTML` or similar raw HTML rendering.
--   **Trigger**: When `pm-agent` flags a task as "High Risk."
--   **Agent**: Primary skill for the `security` agent; secondary skill for `backend`/`review` modes.
+
+- **Trigger**: When `backend` implements an endpoint involving `users`, `auth`, or `payments`.
+- **Trigger**: When `frontend` uses `dangerouslySetInnerHTML` or similar raw HTML rendering.
+- **Trigger**: When `pm-agent` flags a task as "High Risk."
+- **Agent**: Primary skill for the `security` agent; secondary skill for `backend`/`review` modes.
 
 ## The Audit Protocol (The Scanner)
 
 ### 1. Pattern Scanning (The Grep Check)
+
 *Scan the code for these specific "smells":*
 
 | Risk Category | Keywords/Patterns to Flag |
@@ -31,16 +34,18 @@ To act as an automated **SAST (Static Application Security Testing)** scanner.
 | **Debug Leftovers** | `console.log(userObj)`, `debugger`, `0.0.0.0` (binding to all interfaces) |
 
 ### 2. Logic Analysis (STRIDE)
+
 *Ask these questions about the flow:*
-*   **Spoofing**: Does this verify *who* the user is? (Check: Auth Middleware presence).
-*   **Tampering**: Can I modify the payload? (Check: Zod/Joi validation `strip()` on unknown keys).
-*   **Information Disclosure**: Does the error return the stack trace? (Check: `try/catch` blocks).
-*   **Elevation of Privilege**: Does it check `user.id === resource.ownerId`? (Check: Authorization logic).
+- **Spoofing**: Does this verify *who* the user is? (Check: Auth Middleware presence).
+- **Tampering**: Can I modify the payload? (Check: Zod/Joi validation `strip()` on unknown keys).
+- **Information Disclosure**: Does the error return the stack trace? (Check: `try/catch` blocks).
+- **Elevation of Privilege**: Does it check `user.id === resource.ownerId`? (Check: Authorization logic).
 
 ### 3. Dependency Check (Supply Chain)
-*   If `package.json` was modified:
-    *   Are versions pinned? (Good: `1.2.3`, Bad: `^1.2.3`).
-    *   Are there known CVEs? (Trigger `tavily` search).
+
+* If `package.json` was modified:
+  - Are versions pinned? (Good: `1.2.3`, Bad: `^1.2.3`).
+  - Are there known CVEs? (Trigger `tavily` search).
 
 ## Execution Template
 
@@ -85,6 +90,6 @@ To act as an automated **SAST (Static Application Security Testing)** scanner.
 
 ## Integration with Agents
 
--   **`security` agent**: Uses this skill as its primary method of interaction.
--   **`backend` agent**: Must invoke `security-audit` before marking an API task as "Complete."
--   **`review` mode**: Uses the *Findings Table* as the basis for "Critical" comments.
+- **`security` agent**: Uses this skill as its primary method of interaction.
+- **`backend` agent**: Must invoke `security-audit` before marking an API task as "Complete."
+- **`review` mode**: Uses the *Findings Table* as the basis for "Critical" comments.

package/.opencode/skills/self-check/SKILL.md

@@ -6,37 +6,47 @@ description: Post-implementation validation to enforce the Definition of Done (D
 # Self-Check Skill
 
 ## Purpose
+
 To validate work **after** implementation but **before** handoff.
 This is the "Check" in PDCA. It prevents the "It works on my machine" (or "It works in my context window") syndrome.
 
 **ROI Metric**: Catching a syntax error here costs 50 tokens. Catching it in a PR review costs 5,000 tokens + human time.
 
 ## When to Use
--   **Trigger**: Immediately after `execution` mode finishes writing code.
--   **Trigger**: Before the `backend` agent hands off to `frontend`.
--   **Trigger**: Before any `git commit`.
+
+- **Trigger**: Immediately after `execution` mode finishes writing code.
+- **Trigger**: Before the `backend` agent hands off to `frontend`.
+- **Trigger**: Before any `git commit`.
 
 ## The "Proof of Work" Protocol
 
 ### 1. The Build Check (Syntax)
+
 **Rule**: *Code that doesn't build doesn't exist.*
--   Did you run the build/transpile command? (`npm run build`, `go build`, etc.)
--   **Evidence**: Paste the exit code and the last 3 lines of output.
+
+- Did you run the build/transpile command? (`npm run build`, `go build`, etc.)
+- **Evidence**: Paste the exit code and the last 3 lines of output.
 
 ### 2. The Logic Check (Behavior)
+
 **Rule**: *Claims require proof.*
--   **Forbidden Phrase**: "I ran the tests and they passed." (This is often a hallucination).
--   **Required Action**: Run the test command via `run_command` and capture the actual output.
--   **Evidence**: Paste the `Total: X Passed, 0 Failed` line.
+
+- **Forbidden Phrase**: "I ran the tests and they passed." (This is often a hallucination).
+- **Required Action**: Run the test command via `run_command` and capture the actual output.
+- **Evidence**: Paste the `Total: X Passed, 0 Failed` line.
 
 ### 3. The Contract Check (Requirements)
+
 **Rule**: *Did you solve the user's problem?*
--   Map every constraint from the original prompt to a specific line of code or test case.
+
+- Map every constraint from the original prompt to a specific line of code or test case.
 
 ### 4. The Hygiene Check (Cleanup)
+
 **Rule**: *Leave no trace.*
--   Scan for: `console.log("here")`, `debugger`, commented out code blocks, or `TODO` comments added by you.
--   **Action**: Remove them.
+
+- Scan for: `console.log("here")`, `debugger`, commented out code blocks, or `TODO` comments added by you.
+- **Action**: Remove them.
 
 ## Execution Template
 
@@ -53,24 +63,30 @@ This is the "Check" in PDCA. It prevents the "It works on my machine" (or "It wo
   > tsc
   ✨ Done in 2.45s.
   ```
+
 - **Status**: [ PASS / FAIL ]
 
 ### 2. Test Verification
+
 - **Command**: `npm test -- user.service.test.ts`
 - **Output**:
+
   ```text
   PASS src/services/user.service.test.ts
   Tests: 3 passed, 3 total
   ```
+
 - **Status**: [ PASS / FAIL ] -> *If FAIL, trigger `reflexion` skill.*
 
 ### 3. Requirements Mapping
+
 | Requirement | Implemented? | Evidence (File/Line) |
 | :--- | :--- | :--- |
 | "Users must have a role" | ✅ | `UserSchema.ts:12` (Zod enum) |
 | "Passwords must be hashed" | ✅ | `AuthService.ts:45` (bcrypt call) |
 
 ### 4. Code Hygiene
+
 - [ ] Removed debug `console.log`s?
 - [ ] Removed temporary comments?
 - [ ] Ran Linter? (`npm run lint`)
@@ -90,6 +106,6 @@ If you see these patterns in your own reasoning, **STOP**:
 
 ## Integration with Agents
 
--   **`execution` mode**: Must run `self-check` before declaring `Status: COMPLETE`.
--   **`pm-agent`**: Rejects any task update that does not include a `self-check` artifact.
--   **`reflexion` skill**: If `self-check` results in **FAIL**, the agent must immediately enter `reflexion` mode to analyze the root cause before retrying.
+- **`execution` mode**: Must run `self-check` before declaring `Status: COMPLETE`.
+- **`pm-agent`**: Rejects any task update that does not include a `self-check` artifact.
+- **`reflexion` skill**: If `self-check` results in **FAIL**, the agent must immediately enter `reflexion` mode to analyze the root cause before retrying.

package/.opencode/skills/simplification/SKILL.md

@@ -6,47 +6,57 @@ description: Complexity reduction and architectural streamlining for Frontend, B
 # Simplification Skill (Occam's Razor)
 
 ## Purpose
+
 "Simplicity is the ultimate sophistication." This skill provides a rigorous protocol for identifying and eliminating over-engineering, code bloat, and technical debt across the entire stack.
 
 ## Overview
+
 The Simplification Skill is a cross-functional protocol used to flatten logic, reduce state, and ensure every line of code justifies its existence. It leverages specialized agents and MCP tools to validate architectural simplicity and performance.
 
 ## Prerequisites
+
 - **Agents**: [Backend](file:///.opencode/agents/backend.md), [Frontend](file:///.opencode/agents/frontend.md), [Quality](file:///.opencode/agents/quality.md).
-- **MCP Tools**: 
-    - `context7`: To research lightweight alternatives and library standards.
-    - `sequential-thinking`: To audit complex logic flows for potential flattening.
-    - `sqlite`: To verify if database schemas or queries can be compressed.
-    - `playwright`/`chrome-devtools`: To identify UI "jank" or DOM complexity.
+- **MCP Tools**:
+  - `context7`: To research lightweight alternatives and library standards.
+  - `sequential-thinking`: To audit complex logic flows for potential flattening.
+  - `sqlite`: To verify if database schemas or queries can be compressed.
+  - `playwright`/`chrome-devtools`: To identify UI "jank" or DOM complexity.
 
 ## Agent-Specific Simplification Protocols
 
 ### [Senior Backend Engineer](file:///.opencode/agents/backend.md)
+
 - **State Reduction**: Derive values instead of storing them. If `is_active` can be derived from `status === 'active'`, delete the redundant field.
 - **Query Optimization**: Use `sqlite` to check for N+1 issues. Replace nested loops with single optimized queries or batching.
 - **Error Flattening**: Centralize error handling middleware. Remove repetitive `try/catch` blocks from business logic to expose the "Happy Path".
 
 ### [Senior Frontend Engineer](file:///.opencode/agents/frontend.md)
+
 - **DOM Streamlining**: Replace "Div Soup" with semantic HTML elements.
 - **Hook Optimization**: Audit `useEffect` usage. If it's used to sync state, replace it with derived constants or `useMemo`.
 - **Styling Discipline**: Replace custom inline styles with standard Tailwind utility classes or `cva` variants.
 
 ### [QA Automation Engineer](file:///.opencode/agents/quality.md)
+
 - **Test Pruning**: Remove redundant unit tests if the logic is covered by a high-confidence integration test.
 - **Selector Simplification**: Replace fragile XPaths or class-based selectors with accessible `getByRole` or `getByLabel` locators.
 
 ## The Procedural Workflow
 
 ### 1. The Deletion Test
+
 - **Action**: Use `grep_search` to find references to the target code. If references < 1, **DELETE**.
 - **Rule**: Dead code is the best code.
 
 ### 2. The Library Leverage (via `context7`)
+
 - **Action**: Use `context7` to check if a complex custom utility (e.g., date formatting, deep cloning) can be replaced by a native function or a lightweight standard library (Lodash/Zustand).
 
 ### 3. Flat Logic Audit (via `sequential-thinking`)
+
 - **Action**: Step through the logic. If nesting > 3 levels or cyclomatic complexity is high, apply guard clauses.
 - **Target Pattern**:
+
   ```diff
   - if (user) {
   -   if (user.active) {
@@ -58,6 +68,7 @@ The Simplification Skill is a cross-functional protocol used to flatten logic, r
   ```
 
 ## Complexity Metrics to Watch
+
 - **Nesting Level**: Maximum 3 levels of indentation.
 - **Function Size**: Maximum 30 lines.
 - **Cognitive Weight**: If a function requires `sequential-thinking` just to "read" it, it's too complex.
@@ -81,12 +92,15 @@ The Simplification Skill is a cross-functional protocol used to flatten logic, r
 ```
 
 **After**:
+
 ```javascript
 // Streamlined, readable, and efficient code
 ```
 
 ### 3. Impact Assessment
+
 - Lines Removed: [Count]
 - Performance Gain: [e.g., Reduced O(N²) to O(N)]
 - Maintenance Status: Optimized
+
 ```

package/.opencode/skills/tech-debt/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: tech-debt
+description: Technical debt identification, prioritization, and strategic repayment planning.
+---
+
+# Tech Debt Skill
+
+## Purpose
+
+To transform **silent code rot** into **managed, prioritized backlog items**. This skill provides a systematic approach to identifying, quantifying, and scheduling technical debt repayment—preventing the "big bang" rewrite and enabling sustainable development velocity.
+
+**ROI Metric**: Addressing debt early costs 1x. Addressing it late costs 10x. Ignoring it costs 100x (failed projects).
+
+## When to Use
+
+- **Trigger**: When velocity is slowing down (features taking longer).
+- **Trigger**: When `reflexion` identifies recurring issues.
+- **Trigger**: Before major feature work ("Clean the campsite first").
+- **Trigger**: When code complexity metrics exceed thresholds.
+- **Trigger**: When `pm-agent` schedules a "debt sprint."
+
+## The Debt Management Protocol (The 4-Step Process)
+
+### 1. Identification (Where Is The Debt?)
+
+**Scan for these debt signals:**
+
+| Signal | Detection Method | Example |
+|:-------|:-----------------|:--------|
+| **Code Smells** | Static analysis, complexity metrics | Functions >50 lines, nested conditionals >3 levels |
+| **Outdated Dependencies** | `npm outdated`, `cargo outdated` | React 16 when 18 is available |
+| **Missing Tests** | Coverage reports | Critical path has <50% coverage |
+| **Documentation Drift** | Doc vs code comparison | API docs don't match implementation |
+| **Workarounds** | Code comments (`// HACK`, `// FIXME`) | Temporary fixes that became permanent |
+| **Performance Issues** | Profiling, metrics | Page load >3s, API latency >500ms |
+| **Security Vulnerabilities** | `npm audit`, SAST scans | Known CVEs in dependencies |
+
+### 2. Quantification (How Bad Is It?)
+
+Score each debt item across three dimensions:
+
+**Impact (1-10)**: How much does this hurt?
+- Development velocity
+- System reliability
+- Security posture
+- User experience
+
+**Effort (1-10)**: How hard to fix?
+- Lines of code to change
+- Files affected
+- Dependencies to update
+- Tests to write
+- Risk of breaking changes
+
+**Interest Rate (1-10)**: How fast is it growing?
+- How often does this code change?
+- How many new features touch this area?
+- How many workarounds are being added?
+
+**Debt Score = Impact × Interest Rate / Effort**
+
+Higher score = Pay this debt first.
+
+### 3. Categorization (What Type Of Debt?)
+
+| Category | Description | Example | Typical Action |
+|:---------|:------------|:--------|:-------------|
+| **Design Debt** | Architectural shortcuts | God class, tight coupling | Refactor with ADR |
+| **Code Debt** | Implementation shortcuts | Copy-pasted code, long methods | Refactor incrementally |
+| **Test Debt** | Missing or poor tests | No integration tests | Write tests before changes |
+| **Documentation Debt** | Outdated or missing docs | API changes not documented | Update docs as you go |
+| **Dependency Debt** | Outdated libraries | React 16 in 2026 | Scheduled upgrade |
+| **Infrastructure Debt** | Ops shortcuts | Manual deploys | Automate via IaC |
+| **Skill Debt** | Team knowledge gaps | No one knows GraphQL | Training + pairing |
+
+### 4. Scheduling (When Do We Pay?)
+
+**Strategies:**
+
+**A. Debt Sprints (20% Rule)**
+- Reserve 20% of every sprint for debt repayment.
+- Pay highest-scored debt items first.
+- Track debt burndown like feature burndown.
+
+**B. Boy Scout Rule**
+- "Leave the code better than you found it."
+- Small improvements with every feature PR.
+- Limit: 10-20% of PR scope should be cleanup.
+
+**C. Before New Features**
+- Clean debt in the area you're about to modify.
+- Prevents building on shaky foundations.
+
+**D. Scheduled Maintenance**
+- Quarterly dependency updates.
+- Bi-annual architecture reviews.
+- Annual security audits.
+
+## Debt Item Template
+
+```markdown
+# Tech Debt Item: [TITLE]
+
+## Summary
+**ID**: DEBT-XXX  
+**Category**: [Design/Code/Test/Doc/Dependency/Infra/Skill]  
+**Filed Date**: YYYY-MM-DD  
+**Status**: Identified | Scheduled | In Progress | Paid
+
+## Problem Statement
+[What is the debt? What are the symptoms?]
+
+[Example: The UserService class has grown to 2000 lines and handles authentication, profile management, and preferences. Changes require touching 15+ methods.]
+
+## Impact Assessment
+
+| Dimension | Score (1-10) | Justification |
+|:----------|:------------:|:--------------|
+| **Impact** | 8 | Every user feature touches this class. Changes are slow and error-prone. |
+| **Effort** | 6 | Requires splitting into 3-4 services. Estimated 3 days. |
+| **Interest Rate** | 9 | We add 2-3 new user features per sprint. Debt grows fast. |
+
+**Debt Score**: (8 × 9) / 6 = **12.0** [Pay Immediately: >10]
+
+## Symptoms
+- [ ] Feature X took 5 days instead of 2
+- [ ] Bug Y introduced because of tight coupling
+- [ ] Developer onboarding takes 3 days to understand UserService
+- [ ] Tests are flaky due to too many responsibilities
+
+## Proposed Solution
+[What should we do to pay this debt?]
+
+[Example: Split UserService into AuthService, ProfileService, and PreferenceService. Each <300 lines.]
+
+### Steps
+1. [ ] Step 1: Create ProfileService, move profile methods
+2. [ ] Step 2: Update tests for ProfileService
+3. [ ] Step 3: Create PreferenceService, move preference methods
+4. [ ] Step 4: Update tests for PreferenceService
+5. [ ] Step 5: Refactor UserService to AuthService only
+6. [ ] Step 6: Update all imports and calls
+7. [ ] Step 7: Verify all tests pass
+
+## Risks & Mitigations
+- **Risk**: Breaking changes to API → Mitigation: Maintain backward-compatible wrapper during transition
+- **Risk**: Tests need major rewrite → Mitigation: Write new service tests before migration
+
+## Payment Schedule
+- **Strategy**: Before New Feature
+- **Scheduled Sprint**: Sprint 12 (when we build User Preferences v2)
+- **Owner**: @backend-team
+- **Estimated Effort**: 3 days
+
+## Notes
+- **Related PRs**: #123, #456
+- **Related ADRs**: ADR-002 (Service Boundaries)
+- **Outcome (when paid)**: [To be filled]
+```
+
+## Execution Template
+
+*Use this when running a debt audit.*
+
+```markdown
+## 🔍 Tech Debt Audit: [Scope]
+
+### 1. Scan Results
+
+| ID | Category | Location | Impact | Effort | Interest | Score | Priority |
+|:---|:---------|:---------|:------:|:------:|:--------:|:-----:|:--------:|
+| D-001 | Design | UserService.ts | 8 | 6 | 9 | 12.0 | HIGH |
+| D-002 | Dependency | React 16.x | 6 | 4 | 7 | 10.5 | HIGH |
+| D-003 | Test | auth/ | 7 | 3 | 6 | 14.0 | HIGH |
+| D-004 | Code | utils/helpers.js | 4 | 2 | 3 | 6.0 | MEDIUM |
+
+### 2. High Priority Items (Score >10)
+
+#### D-003: Missing Auth Tests
+**Problem**: Authentication flows have 23% test coverage.  
+**Impact**: Every auth change risks regression.  
+**Solution**: Write integration tests for all auth flows.  
+**Effort**: 2 days  
+**Schedule**: Next sprint (Sprint 11)
+
+### 3. Payment Plan
+
+**This Sprint (Sprint 10)**
+- [ ] D-004: Refactor utils/helpers.js (1 day)
+- Feature work: 80%
+- Debt work: 20%
+
+**Next Sprint (Sprint 11)**
+- [ ] D-003: Auth test coverage (2 days)
+- [ ] D-002: React upgrade planning (1 day)
+- Feature work: 70%
+- Debt work: 30%
+
+**Following Sprint (Sprint 12)**
+- [ ] D-001: Split UserService (3 days)
+- Feature work: 60%
+- Debt work: 40%
+
+### 4. Debt Metrics
+- **Total Items**: 4
+- **High Priority**: 3
+- **Estimated Total Effort**: 12 days
+- **Debt Burndown Target**: 0 high-priority items by end of Q2
+```
+
+## Debt Register
+
+Maintain a central debt register:
+
+```markdown
+# Technical Debt Register
+
+## Active Debt
+| ID | Title | Category | Score | Status | Owner | Target Sprint |
+|:---|:------|:---------|:-----:|:-------|:------|:-------------:|
+| D-001 | UserService too large | Design | 12.0 | Scheduled | Backend | 12 |
+| D-002 | React 16 outdated | Dependency | 10.5 | Scheduled | Frontend | 11 |
+| D-003 | Auth tests missing | Test | 14.0 | In Progress | Quality | 11 |
+
+## Recently Paid
+| ID | Title | Category | Paid Date | Effort | Outcome |
+|:---|:------|:---------|:----------|:-------|:--------|
+| D-000 | Legacy API wrapper | Code | 2026-01-15 | 2 days | API response time -30% |
+```
+
+## Integration with Agents
+
+- **`architect`**: Identifies design debt, creates ADRs for major refactors.
+- **`backend` / `frontend`**: Identifies code debt during implementation.
+- **`quality`**: Identifies test debt from coverage reports.
+- **`pm-agent`**: Schedules debt sprints, tracks debt burndown.
+- **`reflexion`**: Surfaces recurring issues that become debt items.
+
+## Anti-Patterns (Avoid)
+
+- ❌ **"We'll fix it later"** without scheduling → Becomes permanent
+- ❌ **Big Bang Rewrite** → High risk, hard to validate
+- ❌ **Perfect is Enemy of Good** → Don't gold-plate while debt accumulates
+- ❌ **Debt Amnesty** → Don't ignore debt because "it's always been there"
+- ❌ **Paying Low-Score Debt First** → Focus on high-impact, high-interest debt

package/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Super-OpenCode
+Copyright (c) 2026 SIO TOU LAI
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal