thachvd-kit 1.0.28 → 1.0.30

package/.agent/workflows/preview.md

@@ -1,81 +0,0 @@
----
-description: Preview server start, stop, and status check. Local development server management.
----
-
-# /preview - Preview Management
-
-$ARGUMENTS
-
----
-
-## Task
-
-Manage preview server: start, stop, status check.
-
-### Commands
-
-```
-/preview           - Show current status
-/preview start     - Start server
-/preview stop      - Stop server
-/preview restart   - Restart
-/preview check     - Health check
-```
-
----
-
-## Usage Examples
-
-### Start Server
-```
-/preview start
-
-Response:
-🚀 Starting preview...
-   Port: 3000
-   Type: Next.js
-
-✅ Preview ready!
-   URL: http://localhost:3000
-```
-
-### Status Check
-```
-/preview
-
-Response:
-=== Preview Status ===
-
-🌐 URL: http://localhost:3000
-📁 Project: C:/projects/my-app
-🏷️ Type: nextjs
-💚 Health: OK
-```
-
-### Port Conflict
-```
-/preview start
-
-Response:
-⚠️ Port 3000 is in use.
-
-Options:
-1. Start on port 3001
-2. Close app on 3000
-3. Specify different port
-
-Which one? (default: 1)
-```
-
----
-
-## Technical
-
-Auto preview uses `auto_preview.py` script:
-
-```bash
-python .agent/scripts/auto_preview.py start [port]
-python .agent/scripts/auto_preview.py stop
-python .agent/scripts/auto_preview.py status
-```
-

package/.agent/workflows/release.md

@@ -1,42 +0,0 @@
----
-description: Release the thachvd-kit npm package with verification, versioning, tagging, publishing, and registry checks.
----
-
-# /release - Npm Release
-
-Use this workflow only after the implementation workflow is complete and the release commit is the only intended change.
-
-## Release Gate
-
-- [ ] Working tree is clean before starting.
-- [ ] Change is already reviewed and pushed to `main`.
-- [ ] `npm run release:verify` passes.
-- [ ] The next version is correct and has not been published.
-- [ ] npm authentication is available with `npm whoami`.
-- [ ] Rollback/response plan is known: npm versions cannot be overwritten or reused.
-
-## Commands
-
-```bash
-git status --short --branch
-npm run release:verify
-npm run release:patch
-git push origin main --follow-tags
-npm whoami
-npm run release:publish
-npm view thachvd-kit version
-npx thachvd-kit@<published-version> --help
-```
-
-`npm run release:patch` runs `preversion`, which executes the release verification, then `npm version patch` updates the package metadata and creates the version commit/tag. Do not run `npm publish` until the version and dry-run contents are correct.
-
-## Version Rules
-
-- Patch: backward-compatible fixes, docs, tests, and internal workflow improvements.
-- Minor: backward-compatible new CLI behavior or user-facing capability.
-- Major: breaking CLI, configuration, package, or generated-artifact contract.
-- Beta/prerelease: publish with a non-`latest` dist-tag, for example `npm publish --tag beta`.
-
-## Bypass Rules
-
-Questions and simple fixes bypass Spec/Plan/Review only when they do not change behavior or a shared contract. Publishing never bypasses `release:verify`, versioning, tagging, authentication, or registry verification.

package/.agent/workflows/review.md

@@ -1,125 +0,0 @@
-# /review — Pre-Merge Code Review
-
-Structured multi-axis review before any change enters the main branch.
-
-> **Rule:** Every change gets reviewed before merge — no exceptions, no shortcuts.
-
----
-
-## When to Use
-
-- Before merging any PR or change
-- After completing a feature implementation
-- When another agent or model produced code you need to evaluate
-- When refactoring existing code
-- After any bug fix (review both fix and regression test)
-
----
-
-## Step 1: Understand the Context
-
-Before looking at code, understand the intent:
-
-```
-- What is this change trying to accomplish?
-- What spec or task does it map to?
-- What could go wrong if this change is wrong?
-```
-
----
-
-## Step 2: Five-Axis Review
-
-Work through each axis in order. Flag issues with 🔴 BLOCKING / 🟡 SUGGESTION / 🟢 NIT.
-
-### Axis 1 — Correctness
-- [ ] Matches spec/task requirements
-- [ ] Edge cases handled (null, empty, boundary values)
-- [ ] Error paths covered
-- [ ] Tests pass and test the right things
-
-### Axis 2 — Readability & Simplicity
-- [ ] Names descriptive and consistent
-- [ ] Could this be done in fewer lines?
-- [ ] No clever tricks that should be simplified
-- [ ] No dead code (no-op variables, `// removed` comments)
-
-### Axis 3 — Architecture
-- [ ] Follows existing patterns (or new pattern justified)
-- [ ] Clean module boundaries
-- [ ] No unnecessary code duplication
-- [ ] No circular dependencies
-
-### Axis 4 — Security
-- [ ] Input validated and sanitized
-- [ ] No secrets in code, logs, or version control
-- [ ] Auth/authz checked where needed
-- [ ] SQL queries parameterized
-- [ ] External data treated as untrusted
-
-### Axis 5 — Performance
-- [ ] No N+1 queries
-- [ ] No unbounded loops or unconstrained fetching
-- [ ] Missing pagination on list endpoints
-- [ ] No unnecessary re-renders in UI
-
----
-
-## Step 3: Change Size Sanity Check
-
-```
-~100 lines changed   → Good
-~300 lines changed   → Acceptable (single logical change)
-~1000+ lines changed → Too large — request a split
-```
-
-If too large, request it be split before reviewing further.
-
----
-
-## Step 4: Write Review Output
-
-Use comment conventions:
-
-```
-🔴 BLOCKING: [Specific issue that must be fixed before merge]
-🟡 SUGGESTION: [Improvement worth considering but not blocking]
-🟢 NIT: [Minor style/preference item]
-❓ QUESTION: [Clarification needed]
-```
-
----
-
-## Approval Standard
-
-Approve when the change **definitely improves overall code health**, even if imperfect.
-
-Do not block because it isn't exactly how you would have written it. If it improves the codebase and follows project conventions, approve it.
-
----
-
-## Anti-Rationalization
-
-| Excuse | Correct Response |
-|--------|-----------------|
-| "It's a small PR, not worth five axes" | Small PRs still introduce bugs. Run all five. |
-| "I wrote this code, I know it's correct" | Author bias is real. Treat it as a stranger's code. |
-| "Tests pass so it's fine" | Tests prove what you tested, not what you didn't. |
-| "No time for a thorough review" | A partial review is a false sense of security. Flag as skipped. |
-| "The security axis doesn't apply here" | Apply it and confirm explicitly — don't silently skip. |
-| "Just reviewing, not approving" | Still run the full checklist. Review = accountability. |
-
----
-
-## Exit Criteria
-
-Before approving or merging:
-
-- [ ] All five axes reviewed (not skimmed)
-- [ ] Change size is appropriate (< ~300 lines for one logical change)
-- [ ] All 🔴 BLOCKING issues resolved or explicitly accepted with rationale
-- [ ] Tests present and passing for changed behavior
-- [ ] No secrets, magic numbers, or hardcoded values
-- [ ] Review decision posted with explicit rationale
-
-**Pairs with:** `code-review-checklist`, `verification-before-completion`, `requesting-code-review`

package/.agent/workflows/simple.md

@@ -1,42 +0,0 @@
----
-description: Fast path for one-file, unambiguous fixes with no behavior or shared-contract change.
----
-
-# /simple - Fast Path
-
-$ARGUMENTS
-
-Codex UI command: `/prompts:simple`. The `/simple` name below describes the workflow; it is not a built-in Codex slash command.
-
-## Use Only When
-
-- The change is limited to one obvious file or one tiny local edit.
-- The expected result is unambiguous.
-- No behavior, API, schema, security, CI, dependency, workflow, or release contract changes.
-
-## Explicit Bypass
-
-Start the response with:
-
-```text
-FAST_PATH: simple-fix
-REASON: [why Spec/Plan/Review are not needed]
-SCOPE: [file or narrow area]
-```
-
-## Steps
-
-1. Inspect the target and its immediate context.
-2. Make the smallest change.
-3. Run focused verification.
-4. Report the changed file and evidence.
-
-Do not create a spec or plan for this route. Do not skip verification. If the scope expands, stop and re-route through `/task` as a feature, bug, or multi-domain task.
-
-## Examples
-
-```text
-/simple fix a typo in README.md
-/simple update one stale command in a workflow doc
-/simple change one test assertion message
-```

package/.agent/workflows/spec.md

@@ -1,140 +0,0 @@
-# /spec — Spec-Driven Development
-
-Write a structured specification before writing any code.
-
-> **Rule:** Code without a spec is guessing. The spec is the shared source of truth.
-
----
-
-## When to Use
-
-Use `/spec` when:
-- Starting a new project or feature
-- Requirements are ambiguous or incomplete
-- The change touches multiple files or modules
-- You're about to make an architectural decision
-- The task would take more than 30 minutes to implement
-
-**Skip when:** Single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained.
-
----
-
-## The Gated Workflow
-
-Do not advance to the next phase without human validation.
-
-```
-SPECIFY ──→ PLAN ──→ TASKS ──→ IMPLEMENT
-   │          │        │          │
-   ▼          ▼        ▼          ▼
- Human      Human    Human      Human
- reviews    reviews  reviews    reviews
-```
-
----
-
-## Phase 1: Surface Assumptions First
-
-Before writing any spec content, explicitly state what you're assuming:
-
-```
-ASSUMPTIONS I'M MAKING:
-1. [assumption about tech stack or framework]
-2. [assumption about architecture]
-3. [assumption about scope or boundaries]
-→ Correct me now or I'll proceed with these.
-```
-
-Do not silently fill in ambiguous requirements.
-
----
-
-## Phase 2: Write the Spec
-
-Create a spec document in `docs/spec-[feature-name].md` covering six areas:
-
-### 1. Objective
-What are we building and why? Who is the user? What does success look like?
-
-### 2. Commands
-Full executable commands with flags:
-```
-Build: npm run build
-Test: npm test
-Lint: npm run lint
-Dev: npm run dev
-```
-
-### 3. Project Structure
-Where source code lives, where tests go, where docs belong:
-```
-src/           → Application source
-src/components → Components
-tests/         → Unit and integration tests
-```
-
-### 4. Code Style
-One real code snippet showing style beats three paragraphs describing it. Include naming conventions and examples.
-
-### 5. Testing Strategy
-Framework, where tests live, coverage expectations, which test levels for which concerns.
-
-### 6. Boundaries (Three-Tier)
-- **Always do:** Run tests before commits, follow naming conventions
-- **Ask first:** Database schema changes, adding dependencies, changing CI config
-- **Never do:** Commit secrets, remove failing tests without approval
-
----
-
-## Spec Template
-
-```markdown
-# Spec: [Feature Name]
-
-## Objective
-[What we're building and why. User stories or acceptance criteria.]
-
-## Tech Stack
-[Framework, language, key dependencies with versions]
-
-## Commands
-[Build, test, lint, dev commands — exact flags]
-
-## Project Structure
-[Key directories and what goes where]
-
-## Code Style
-[One code example showing conventions]
-
-## Testing Strategy
-[Framework, location, coverage target, test levels]
-
-## Boundaries
-- Always: ...
-- Ask first: ...
-- Never: ...
-```
-
----
-
-## Anti-Rationalization
-
-| Excuse | Correct Response |
-|--------|-----------------|
-| "Requirements are clear, no need for a spec" | Write a one-page spec to confirm. Misalignments appear during writing, not before. |
-| "We'll figure out details during implementation" | Ambiguities discovered during coding are more expensive. Resolve them now. |
-| "The spec will become outdated" | A living spec that's 80% right is better than no spec. Update it as you learn. |
-| "This is too small for a spec" | If it takes more than 30 minutes, it needs a spec. Estimate conservatively. |
-| "I already know what to build" | Write it down to confirm alignment, then proceed. |
-
-## Exit Criteria
-
-Before moving from spec to plan:
-
-- [ ] Assumptions explicitly listed and confirmed by human
-- [ ] Spec document covers all six areas (objective, commands, structure, style, testing, boundaries)
-- [ ] Human has reviewed and approved the spec
-- [ ] No ambiguous requirements remain open
-- [ ] Spec saved as `docs/spec-[feature-name].md` or equivalent location
-
-**Pairs with:** `plan-writing`, `tdd-workflow`, `verification-before-completion`

package/.agent/workflows/status.md

@@ -1,86 +0,0 @@
----
-description: Display agent and project status. Progress tracking and status board.
----
-
-# /status - Show Status
-
-$ARGUMENTS
-
----
-
-## Task
-
-Show current project and agent status.
-
-### What It Shows
-
-1. **Project Info**
-   - Project name and path
-   - Tech stack
-   - Current features
-
-2. **Agent Status Board**
-   - Which agents are running
-   - Which tasks are completed
-   - Pending work
-
-3. **File Statistics**
-   - Files created count
-   - Files modified count
-
-4. **Preview Status**
-   - Is server running
-   - URL
-   - Health check
-
----
-
-## Example Output
-
-```
-=== Project Status ===
-
-📁 Project: my-ecommerce
-📂 Path: C:/projects/my-ecommerce
-🏷️ Type: nextjs-ecommerce
-📊 Status: active
-
-🔧 Tech Stack:
-   Framework: next.js
-   Database: postgresql
-   Auth: clerk
-   Payment: stripe
-
-✅ Features (5):
-   • product-listing
-   • cart
-   • checkout
-   • user-auth
-   • order-history
-
-⏳ Pending (2):
-   • admin-panel
-   • email-notifications
-
-📄 Files: 73 created, 12 modified
-
-=== Agent Status ===
-
-✅ database-architect → Completed
-✅ backend-specialist → Completed
-🔄 frontend-specialist → Dashboard components (60%)
-⏳ test-engineer → Waiting
-
-=== Preview ===
-
-🌐 URL: http://localhost:3000
-💚 Health: OK
-```
-
----
-
-## Technical
-
-Status uses these scripts:
-- `python .agent/scripts/session_manager.py status`
-- `python .agent/scripts/auto_preview.py status`

package/.agent/workflows/task.md

@@ -1,59 +0,0 @@
----
-description: Route every task to the smallest safe workflow, fast path, bug flow, feature flow, or release flow.
----
-
-# /task - Task Router
-
-$ARGUMENTS
-
-Codex UI command: `/prompts:task`. The `/task` name below describes the workflow; it is not a built-in Codex slash command.
-
-## Purpose
-
-Use `/task` at the start of a task when you are unsure which workflow, skill, or specialist agent applies. This command routes the request before implementation.
-
-## Required Output
-
-```text
-ROUTE: question | simple | feature | bug | review | release | multi-domain
-WORKFLOW: [exact .agent/workflows/<name>.md file]
-SKILLS: [skills to load, or none]
-AGENTS: [specialist agents to load, or none]
-GATE: fast-path | standard
-NEXT: [the next command or action]
-```
-
-Do not write code while routing. Ask one concise clarification question if the route cannot be determined safely.
-
-## Routing Rules
-
-| Signal | Route | Next action |
-|---|---|---|
-| Asking for information or architecture explanation | question | Answer directly; no edits |
-| One obvious file, no behavior or contract change | simple | Use `/simple <request>` |
-| New behavior, multiple files, unclear scope, or >30 minutes | feature | `/brainstorm` -> `/spec` when needed -> `/plan`, then approval |
-| Failing test, regression, error, or unknown root cause | bug | Use `/debug <symptom>` |
-| Review request or pre-merge check | review | Use `/review` |
-| npm version/tag/publish request | release | Use `/release` |
-| Several specialist domains | multi-domain | Use `/orchestrate` |
-
-## Workflow And Skill Map
-
-- `/simple`: `$clean-code` + `$verification-before-completion`.
-- `/brainstorm`: `brainstorming`; no code.
-- `/spec`: `.agent/workflows/spec.md`; define scope and acceptance criteria, no code.
-- `/plan`: `project-planner` + `plan-writing`; no code before approval.
-- `/enhance` or `/create`: relevant domain agent and implementation skills after approval.
-- `/debug`: `debugger` + `$systematic-debugging` + `testing-patterns`.
-- `/test`: `test-engineer` + `testing-patterns`.
-- `/review`: `$code-review-checklist` + `$verification-before-completion`.
-- `/release`: `release.md` and the npm release scripts; never use the fast path.
-
-## Examples
-
-```text
-/task add an export button
-/task login returns 500
-/task fix typo in README
-/task publish a new npm version
-```