From f8436e9755be78acf303e646e955220036c05072 Mon Sep 17 00:00:00 2001 From: syntaxbullet Date: Thu, 15 Jan 2026 11:13:37 +0100 Subject: [PATCH] chore: (agent) remove tickets and skills --- .agent/skills/create-ticket/SKILL.md | 51 ------------------ .agent/skills/review/SKILL.md | 54 ------------------- .../001-refactor-command-validation.md | 30 ----------- .../work/tickets/003-modularize-web-server.md | 32 ----------- .../work/tickets/005-refactor-exam-logic.md | 29 ---------- 5 files changed, 196 deletions(-) delete mode 100644 .agent/skills/create-ticket/SKILL.md delete mode 100644 .agent/skills/review/SKILL.md delete mode 100644 .agent/work/tickets/001-refactor-command-validation.md delete mode 100644 .agent/work/tickets/003-modularize-web-server.md delete mode 100644 .agent/work/tickets/005-refactor-exam-logic.md diff --git a/.agent/skills/create-ticket/SKILL.md b/.agent/skills/create-ticket/SKILL.md deleted file mode 100644 index f854aea..0000000 --- a/.agent/skills/create-ticket/SKILL.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -name: create-ticket -description: Create a ticket for a task that needs to be worked on. ---- - -# Skill: create-ticket - -## Purpose - -Decompose high-level objectives into "Atomic Tickets" to maximize development velocity and minimize cognitive overhead. - -## Execution Rules - -1. **Directory Check:** Scan `.agent/work/tickets/`. Determine sequence number `NNN`. -2. **Naming:** `.agent/work/tickets/NNN-brief-description.md`. -3. **The Atomic/Velocity Test:** - Max 3 files modified. - - Max 80 lines of logic. - - Must be verifiable via a single command or test suite. - - If it exceeds these, **split it.** -4. **Context Injection:** Include relevant code snippets or interface definitions directly in the ticket to prevent "context hunting." -5. **No Breaking Changes:** If a ticket changes a shared interface, it must include the refactor for consumers or be split into a "Transition" ticket. - -## Ticket Template - -### Context & Goal - -[Why this matters + the specific problem it solves.] - -### Dependencies - -- [e.g., Ticket #NNN] - -### Affected Files - -- `path/to/file_A.ext`: [Specific change description] -- `path/to/file_B.ext`: [Specific change description] - -### Technical Constraints & Strategy - -- [e.g., Implementation: Use the existing X wrapper instead of a new fetch call.] -- [e.g., Constraint: Maintain backward compatibility with Y.] - -### Definition of Done (Binary) - -- [ ] Criterion 1 (e.g., `npm test` passes for `X.test.ts`) -- [ ] Criterion 2 (e.g., UI component renders without hydration errors) -- [ ] Criterion 3 (e.g., API response matches the schema in `types.ts`) - -### New Test Files - -- `path/to/test_A.ext`: [What is being tested] diff --git a/.agent/skills/review/SKILL.md b/.agent/skills/review/SKILL.md deleted file mode 100644 index 8481d15..0000000 --- a/.agent/skills/review/SKILL.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -name: code-review -description: A "Default-to-Fail" audit of codebase changes. Observation only; no file modifications. ---- - -# Skill: code-review - -## Purpose - -Protect the codebase from "feature creep," technical debt, and weak validation. This skill assumes the latest changes are flawed until they pass a rigorous audit. - -## Execution Rules - -1. **Read-Only Protocol:** This is a diagnostic skill. **Under no circumstances should any files be modified.** Provide feedback only. -2. **Default-to-Fail:** Assume the code is broken or insufficient. The burden of proof lies on the code and its tests. -3. **The Atomic Veto:** - Check the diff. If it exceeds 3 files or 80 lines of logic, **Veto immediately.** - - Reason: "Change exceeds atomic threshold; high risk of cognitive load." -4. **Strictness Audit (Tests):** - - **Veto** if assertions are fuzzy (e.g., `toBeTruthy()`). - - **Veto** if there is no "Red Path" (failure case) test. - - **Veto** if the test is "loose" (e.g., doesn't check specific property values). -5. **Direct Feedback:** No sycophancy. Use "Blockers" for issues and "Verdict: APPROVE" only when the code is bulletproof. - -## Review Template - -### Verdict: [FAIL / APPROVE] - -**Primary Blocker:** [One sentence identifying the biggest reason for rejection.] - ---- - -### 1. Atomic Constraint Check - -- **Files Changed:** [Count] / 3 -- **Logic Lines:** [Count] / 80 -- **Status:** [PASS / FAIL (Veto if FAIL)] - -### 2. Test Strictness Audit - -- **Assertion Quality:** [List specific lines with fuzzy matchers. Demand strict equality.] -- **Failure Coverage:** [Does a test exist for the 'Error/Empty' state? If no, FAIL.] -- **Logic Sync:** [Does the test actually exercise the logic added, or just side effects?] - -### 3. Logic & Resilience - -- **Unchecked States:** [Identify unhandled nulls, undefineds, or missing error catches.] -- **Efficiency:** [Is there a faster path or a redundant operation?] - -### 4. Direct Actionables - -_Note: The reviewer does not apply these. The user/agent must create a ticket or apply fixes manually._ - -1. [Specific fix for Blocker 1] -2. [Specific fix for Blocker 2] diff --git a/.agent/work/tickets/001-refactor-command-validation.md b/.agent/work/tickets/001-refactor-command-validation.md deleted file mode 100644 index 9c0c946..0000000 --- a/.agent/work/tickets/001-refactor-command-validation.md +++ /dev/null @@ -1,30 +0,0 @@ -### Context & Goal - -Currently, every command manually performs checks like user existence or maintenance mode, or these are hardcoded into the `CommandHandler`. Standardizing these requirements in the command definition itself makes the code cleaner and more declarative. - -### Dependencies - -- None - -### Affected Files - -- `shared/lib/types.ts`: Update `Command` interface to include a optional `requirements` object. -- `bot/lib/handlers/CommandHandler.ts`: Update to read and enforce these requirements. -- `bot/commands/economy/balance.ts`: Refactor to use the new requirements (example). - -### Technical Constraints & Strategy - -- Implementation: Use a standardized `requirements` object in the `Command` interface. -- Requirements could include: `userExists: boolean`, `permissions: string[]`, `devOnly: boolean`. -- Ensure `CommandHandler` provides clear error messages to the user when a requirement fails. - -### Definition of Done (Binary) - -- [ ] `Command` interface updated in `types.ts`. -- [ ] `CommandHandler.ts` enforces requirements before executing command. -- [ ] At least one command (e.g., `balance`) is refactored to use the new system. -- [ ] Clear error embeds are shown to the user when requirements aren't met. - -### New Test Files - -- None (Verification via manual testing of command execution). diff --git a/.agent/work/tickets/003-modularize-web-server.md b/.agent/work/tickets/003-modularize-web-server.md deleted file mode 100644 index 45b7db2..0000000 --- a/.agent/work/tickets/003-modularize-web-server.md +++ /dev/null @@ -1,32 +0,0 @@ -### Context & Goal - -The current `web/src/server.ts` is a monolithic file with a very long `fetch` handler. This makes it difficult to read and maintain. Modularizing the logic into separate route handlers and middleware-like functions will improve code quality and scalability. - -### Dependencies - -- None - -### Affected Files - -- `web/src/server.ts`: Refactor to use modular handlers. -- `web/src/routes/api.ts`: New file for API route definitions. -- `web/src/routes/static.ts`: New file for static file serving logic. -- `web/src/routes/websocket.ts`: New file for WebSocket event handling. - -### Technical Constraints & Strategy - -- Implementation: Move different responsibilities (API, Static, WS) into separate files. -- The main `serve` configuration should just call these modules. -- Ensure the SPA fallback logic remains intact. - -### Definition of Done (Binary) - -- [ ] `web/src/server.ts` length reduced by at least 50%. -- [ ] API routes moved to dedicated module. -- [ ] Static file serving moved to dedicated module. -- [ ] WebSocket logic moved to dedicated module. -- [ ] Dashboard still loads and functions correctly. - -### New Test Files - -- None (Verification via manual testing of the dashboard). diff --git a/.agent/work/tickets/005-refactor-exam-logic.md b/.agent/work/tickets/005-refactor-exam-logic.md deleted file mode 100644 index 3c65355..0000000 --- a/.agent/work/tickets/005-refactor-exam-logic.md +++ /dev/null @@ -1,29 +0,0 @@ -### Context & Goal - -The `exam` command currently contains a lot of business logic, including reward calculations, timer management, and complex database transactions. Moving this logic to a dedicated `ExamService` will improve testability, maintainability, and keep the command file focused on user interaction. - -### Dependencies - -- None - -### Affected Files - -- `shared/modules/economy/exam.service.ts`: New file for the exam logic. -- `bot/commands/economy/exam.ts`: Refactor to use the new service. - -### Technical Constraints & Strategy - -- Implementation: Create an `ExamService` that handles `getExamStatus`, `takeExam`, and `registerForExam`. -- The command should only handle user input and formatting the response embeds based on the service's result. -- Ensure the Drizzle transactions are correctly handled within the service. - -### Definition of Done (Binary) - -- [ ] `ExamService` implemented with methods for all exam-related operations. -- [ ] `bot/commands/economy/exam.ts` refactored to use the service. -- [ ] Logic is covered by unit tests in a new test file. -- [ ] Manual verification shows the exam command still works as expected. - -### New Test Files - -- `shared/modules/economy/exam.service.test.ts`: Unit tests for reward calculations and state transitions.