@ryuenn3123/agentic-senior-core 4.4.0 → 5.2.0

package/skills/asc-review/SKILL.md

@@ -0,0 +1,54 @@
+# Review Skill
+
+Production-risk code review. Prioritize findings by severity.
+
+## Before Reviewing
+
+1. Read the changed files and understand the scope.
+2. For UI changes, check accessibility and design consistency.
+3. For API changes, check contract stability and documentation sync.
+
+## Finding Priority Order
+
+1. Correctness, data loss, security, privacy, auth, and permission risks.
+2. Public contract drift: APIs, events, CLI behavior, data model, UI contract, docs.
+3. Missing tests for changed behavior.
+4. Architecture boundary drift and maintainability risk.
+5. Performance and accessibility issues with concrete impact.
+
+## For Every Finding
+
+- Include file and line reference.
+- Explain the real risk.
+- Propose the smallest safe fix.
+
+## Checklist
+
+### Correctness
+- Changed behavior matches the user request.
+- Existing behavior preserved unless user approved a change.
+- Edge cases, empty states, error paths handled.
+
+### Security
+- External input validated at trust boundaries.
+- Secrets, tokens, credentials not committed or logged.
+- Authorization enforced at a trusted boundary.
+- Error responses do not leak internals.
+
+### Architecture
+- Layer boundaries clear. Controllers do not hold business logic.
+- No premature abstraction. No clever hacks.
+- Complexity budget applied: fewer moving parts without losing safety.
+
+### Testing
+- Changed behavior has appropriate tests.
+- Tests assert behavior and contracts, not implementation trivia.
+- Critical flows include failure-path coverage.
+
+### Documentation
+- API, event, CLI, and data contract changes update docs in the same commit.
+- Root README exists and stays current.
+
+## Output
+
+Report findings ordered by severity with file/line references and concrete fixes. If no findings, say so explicitly and name any residual risk.

package/.agent-context/policies/llm-judge-threshold.json

@@ -1,29 +0,0 @@
-{
-  "selectedProfile": "beginner",
-  "profileThresholds": {
-    "beginner": {
-      "blockingSeverities": [
-        "critical"
-      ],
-      "failOnMalformedResponse": false,
-      "failOnProviderError": false
-    },
-    "balanced": {
-      "blockingSeverities": [
-        "critical",
-        "high"
-      ],
-      "failOnMalformedResponse": true,
-      "failOnProviderError": false
-    },
-    "strict": {
-      "blockingSeverities": [
-        "critical",
-        "high",
-        "medium"
-      ],
-      "failOnMalformedResponse": true,
-      "failOnProviderError": true
-    }
-  }
-}

package/.agent-context/prompts/bootstrap-design.md

@@ -1,63 +0,0 @@
-# Design Direction Prompt
-
-Use this prompt for UI, UX, frontend layout, screen, or redesign work. Create or refine `docs/DESIGN.md` before writing UI code.
-
-## Authority
-
-- Use current repo evidence, project docs, and `.agent-context/` as style context.
-- Do not copy layout rhythm, palette, component skin, or brand posture from external references without explicit user approval.
-- WCAG 2.2 AA is the hard compliance floor.
-- When generating any UI component that renders or accepts user data, explicitly state in the prompt: "ensure all user-supplied input is sanitized, all status indicators have non-color alternatives, and all interactive elements have visible focus states."
-- Before choosing a new UI library, research current official docs.
-
-## Design Direction Process
-
-1. **Name Your Defaults**: Name three temptations (e.g. SaaS admin default, AI-startup landing) and why they flatten this product. Derive your search direction by rejecting them.
-2. **Choose an Anchor**: Run `npx -y getdesign@latest list` to browse proven brand references. Pick one whose spatial rhythm fits this product. Run `npx -y getdesign@latest add <brand>` to read the full reference — use it to derive token values, then discard it. Output DESIGN.md stays under 400 tokens. Do not use generic quality words ("clean", "modern").
-3. **Creative Commitments**: Choose distinctive typography, dominant colors with sharp accents, and one signature motion behavior. Create depth rather than flat card stacks.
-4. **Previous Directions**: If `docs/DESIGN.md` contains previous directions, treat them as a blocklist. The new anchor must differ in conceptual family, hierarchy, and motion.
-
-## Redesign Protocol
-
-When the user says "redesign from zero": treat existing UI as behavioral evidence only. Rewrite design docs. Change primary composition, hierarchy, interaction model, and responsive architecture. Do not ship a palette swap.
-
-## Output Format
-
-`docs/DESIGN.md` must be a compact token file under 400 tokens. Rationale stays in working memory.
-
-Required sections (in this order, no additions):
-
-### Anchor
-One sentence: the interaction anchor and what mechanic is borrowed.
-
-### Tokens
-- **Typography**: font families (display, body, mono), scale base and ratio, scale method
-- **Colors**: OKLCH primitives with semantic role mapping (primary, secondary, surface, error, success)
-- **Spacing**: base unit, scale
-- **Radius**: small, medium, large values
-- **Shadow**: elevation levels
-- **Motion**: duration, easing, reduced-motion fallback
-
-### Constraints
-- WCAG 2.2 AA floor
-- Up to 3 product-specific anti-patterns
-
-### Previous Directions
-Anchors used in prior iterations (blocklist for redesign). Start empty for fresh projects.
-
-## Required Validation Gates
-
-Only three gates. Do not add more:
-1. Anchor exists and is specific.
-2. Token values are derived from the anchor.
-3. WCAG 2.2 AA compliance floor is met.
-
-## Pre-Commit Critique
-
-Before committing any UI output, answer:
-
-1. Rename test: if the product name changed to an unrelated category, would this UI still look identical? Yes = too generic, reset anchor.
-2. Token drift test: does any color, font, or spacing in the output contradict the DESIGN.md token definitions? Yes = align before commit.
-3. Security test: is user-controlled data rendered unsanitized, or does any status depend on color alone? Yes = fix before merge.
-
-Max 3 revision cycles. If unresolved, reset the anchor entirely.

package/.agent-context/prompts/compact-natural-mode.md

@@ -1,100 +0,0 @@
-# Compact Natural Mode
-
-Status: active default response contract.
-
-Use this prompt for final user-facing replies after the task-specific rule, prompt, checklist, and validation work is complete.
-
-## Purpose
-
-Write the smallest complete answer that still lets the next developer act correctly.
-
-Compact means high signal. It does not mean broken grammar, dialect, clipped fragments, or hiding evidence.
-
-## Always Remove
-
-- greetings, affirmations, and repeated restatements
-- narration about what you are about to do
-- generic closing offers
-- padding paragraphs that add no new technical content
-- repeated summaries of the same decision
-
-## Always Preserve
-
-- exact commands
-- exact file paths and line numbers
-- exact error messages, assertions, exit codes, and stack-trace highlights
-- validation status, including tests not run
-- assumptions, scope qualifiers, blockers, risks, and next actions
-- destructive-operation warnings
-- breaking changes and migration notes
-
-## Task Shapes
-
-Use natural prose inside these shapes. Omit fields that do not apply, except safety fields.
-
-Debug/root cause:
-
-```text
-Root Cause: <one sentence>
-Evidence: <exact error, command output, or file:line>
-Fix: <exact command or code direction>
-Next: <verification step>
-```
-
-Test failure:
-
-```text
-Failed: <test name>
-Expected/Got: <value> / <value>
-At: <file:line>
-Evidence: <exact assertion or root error>
-Fix direction: <one sentence>
-```
-
-Code review finding:
-
-```text
-[critical|warn|nit] <file>:<line> - <concern>. <requested change>
-```
-
-Implementation/refactor summary:
-
-```text
-Changed: <what changed>
-Reason: <why>
-Behavior: <changed, unchanged, or not verified>
-Validation: <what ran or was not run>
-Risk: <only if relevant>
-```
-
-Destructive command:
-
-```text
-WARNING: <what this destroys and whether it is reversible>
-Command: <exact command>
-Precondition: <what must be true before running>
-```
-
-Security finding:
-
-```text
-Severity: <critical|high|medium|low>
-Class: <vulnerability class>
-Location: <file:line>
-Impact: <who or what is affected>
-Evidence: <exact code, behavior, or command output>
-Remediation: <specific fix direction>
-Validation: <how to prove it is fixed>
-```
-
-Planning/architecture may be longer. Keep decision, rationale, alternatives, tradeoffs, assumptions, and open questions visible.
-
-## Second-Pass Check
-
-Before finalizing:
-
-1. Remove any sentence that adds no new technical content.
-2. Confirm mandatory evidence atoms remain exact.
-3. Confirm assumptions and validation gaps are visible.
-4. Confirm the answer has a decision or next action when the user asked for one.
-5. Confirm the tone is natural professional writing.

package/.agent-context/prompts/init-project.md

@@ -1,60 +0,0 @@
-# Project Initialization Prompts
-
-This prompt boots a repository with strict AI coding guidance context.
-
-## System Directives (Auto Execution)
-
-When a new project is created or initialized, the agent must automatically:
-1. Read [AGENTS.md](../../AGENTS.md) to understand the canonical bootstrap chain and active entrypoints.
-2. Resolve the smallest relevant rule set from [.agent-context/rules/](../rules/) instead of scanning the whole directory by default.
-3. Review dynamic runtime signals from [.agent-context/state/onboarding-report.json](../state/onboarding-report.json), repository evidence, task constraints, and live official documentation when runtime or ecosystem facts matter.
-4. If Docker or Compose is in scope, load [docker-runtime.md](../rules/docker-runtime.md) and verify the latest official Docker guidance before authoring container assets. Materialize the selected development/production assets rather than stopping at prose.
-5. For unresolved framework or package setup, recommend the latest stable compatible dependency set and official framework setup flow from live official documentation before coding unless a documented compatibility constraint blocks it.
-6. Do not default fresh web projects to Next.js, Tailwind-only styling, shadcn/ui, Vite, or any framework by habit, and do not avoid them because of this guard when they are the strongest fit. Treat explicit user constraints as constraints; otherwise compare project needs, runtime boundaries, hosting, data flow, team workflow, and official setup guidance before recommending.
-
-## Required Planning Mode
-
-If the user describes a project or feature, the agent must:
-1. Before drafting docs from a thin or ambiguous brief, ask the smallest useful set of clarifying questions needed to make delivery goals, edge cases, constraints, must-have capabilities, and non-goals explicit. If the user wants a draft anyway, document assumptions and wait for approval before coding.
-2. If the user already named a stack or framework, treat it as an explicit constraint. If not, produce a short evidence-backed recommendation from the brief, repo evidence, and live official documentation before coding. Include at least one plausible alternative when the default-looking option is Next.js, Tailwind-only styling, shadcn/ui, or another familiar web stack.
-3. For existing projects, inspect real files first. Do not derive product name, description, runtime, architecture, or design direction from the folder name alone.
-4. Draft a high-level structure plan plus the docs/bootstrap artifacts that must exist before coding.
-5. Wait for user approval before scaffolding the project.
-
-## Documentation-First Requests
-
-If the user asks to create, complete, fix, or review project docs, documentation, dokumen, `docs/*`, architecture docs, flow docs, API docs, or "lengkapkan docs", treat the request as documentation-first.
-
-The agent must:
-1. Materialize or refine required project docs before implementation: root `README.md` for every fresh or existing project; `docs/doc-index.md` whenever `docs/` exists; `docs/project-brief.md`; `docs/architecture-decision-record.md`; `docs/flow-overview.md`; `docs/api-contract.md` when APIs, firmware endpoints, CLI commands, or web application flows exist; `docs/database-schema.md` when persistent data exists; and `docs/DESIGN.md` for UI scope.
-2. Write formal project docs in English by default unless the user explicitly asks for another documentation language.
-3. Keep `docs/doc-index.md` short. Use it as the read-routing map with document path, purpose, reads-when triggers, status, and last-updated date. Do not duplicate the docs it points to.
-4. Keep `README.md` public and developer friendly even for private projects: explain what the project is, who it is for, how to set it up, how to run the core workflow, how to configure it, and where deeper docs live. Do not put internal agent notes, private reasoning, secrets, or governance policy in the README.
-5. Keep documentation alive. When project behavior, setup, architecture, public contracts, data shape, deployment, or UI scope changes, update the matching docs in the same change.
-6. Avoid documentation sprawl. Add a new docs file only when the topic is stable, long enough to outgrow the README or core docs, or owned by a separate workflow such as hardware setup, deployment, troubleshooting, or testing validation.
-7. Add PRD, SRS, technical-design, or separate ERD only when evidence triggers them. Use PRD for product roadmap/user-story ownership, SRS for contractual or multi-stakeholder acceptance criteria, technical-design for non-trivial architecture decisions, and a separate ERD only when `docs/database-schema.md` cannot stay readable with an embedded diagram.
-8. Stop after docs when the user only asked for docs. Do not write application, firmware, or UI code until the user explicitly asks for implementation or approves the implementation plan.
-
-## Direct Constraint Mode
-
-If the user specifies a framework, runtime, or architecture constraint, the agent must:
-1. Read [AGENTS.md](../../AGENTS.md) for role context.
-2. Resolve only the rules required by the explicit constraint and scope. Do not read unrelated backend, frontend, or DevOps rules by habit.
-3. Reference [.agent-context/state/onboarding-report.json](../state/onboarding-report.json), [AGENTS.md](../../AGENTS.md), and the relevant `.agent-context/` files for runtime evidence and any explicit constraints already applied to this project.
-4. Scaffold the initial project structure only after runtime and architecture decisions are explicit:
-   - Create only the directories and files justified by the approved structure.
-   - Set up configuration, validation, error handling, observability, health checks, and persistence only when they fit the approved runtime and project scope.
-   - Every module must follow [architecture.md](../rules/architecture.md).
-   - New code must pass the natural implementation pass in [architecture.md](../rules/architecture.md): start with the simplest correct flow, add complexity only when the requirement or repo evidence needs it, and do not add files or layers for small tasks.
-   - Use official framework setup commands or canonical starter flows when they produce newer, better-supported dependency defaults than manual package assembly.
-   - Do not assemble a framework project from scratch by habit when official setup commands create the supported structure. Manual assembly is allowed only for tiny prototypes, educational demos, unusual repo constraints, or a documented architecture reason.
-   - If containerization is selected, Docker assets must follow [docker-runtime.md](../rules/docker-runtime.md) and the latest official Docker docs instead of stale blog-era patterns. Selected Docker lanes require files and runbooks, not docs-only acknowledgment.
-
-## Runtime and Architecture Reference
-
-See [.agent-context/state/onboarding-report.json](../state/onboarding-report.json), [AGENTS.md](../../AGENTS.md), and the relevant `.agent-context/` files for the latest shipped runtime evidence, explicit constraints, and agent-decision status.
-
-## UI/UX Bootstrap
-
-When a user requests frontend or UI/UX design, the agent must automatically execute the [bootstrap-design.md](./bootstrap-design.md) prompt to synthesize a dynamic markdown design contract (`docs/DESIGN.md`).
-Keep UI-only requests context-isolated: load [bootstrap-design.md](./bootstrap-design.md) and [frontend-architecture.md](../rules/frontend-architecture.md) first, and do not eagerly load backend-only rules unless the task explicitly crosses backend boundaries.

package/.agent-context/prompts/refactor.md

@@ -1,38 +0,0 @@
-# Prompt: Refactor Code
-
-Use this when code needs cleanup, splitting, or safer structure without changing user-visible behavior.
-
-```text
-Refactor the target code while preserving existing behavior.
-
-Before editing:
-1. Read AGENTS.md and the smallest relevant rules from .agent-context/rules/.
-2. Inspect the real repo conventions before introducing a new structure.
-3. If required project docs are missing, stop and bootstrap or update docs first.
-4. If the change touches UI, load .agent-context/prompts/bootstrap-design.md and .agent-context/rules/frontend-architecture.md before editing.
-5. If the change touches a dependency, framework, Docker, runtime, or ecosystem claim, verify current official docs before choosing.
-6. Enforce Universal SOP hard gate: stop implementation if root `README.md` is missing, if `docs/doc-index.md` is missing while `docs/` exists, if `docs/project-brief.md` is missing, if `docs/architecture-decision-record.md` is missing, if `docs/flow-overview.md` is missing, if `docs/database-schema.md` is missing while the project uses persistent data, if `docs/api-contract.md` is missing while the project exposes API or web application flows, or for UI scope if `docs/DESIGN.md` is missing.
-7. Enforce backend universal principles: no clever hacks, no premature abstraction, readability over brevity.
-8. For backend/API scope, enforce layered boundaries, zero-trust input validation, safe centralized error responses, bounded list reads, transaction safety for multi-write mutations, idempotency for sensitive mutations, and behavior-focused API tests.
-9. Backend/API governance is global and stack-agnostic. Do not create stack-specific adapters or framework-specific rule branches; apply the global rules through the framework already present in the target project.
-10. Enforce the complexity budget: choose fewer moving parts only when behavior, safety, clarity, and maintainability stay intact.
-
-Refactor rules:
-- Improve clarity, boundaries, naming, validation, error handling, tests, and docs.
-- Prioritize maintainability over compressed one-liners.
-- Apply the natural implementation pass from architecture.md: keep the main flow traceable, use early returns where they reduce nesting, and avoid helper chains that only make the code look abstract.
-- Do not choose a stack, framework, library, or topology from offline assumptions.
-- Keep module boundaries explicit and project-specific.
-- Split large files when the split makes the flow easier to understand.
-- Do not introduce abstractions before the repeated pattern is real.
-- Remove code that does not carry behavior, safety, clarity, maintainability, or test value.
-- Prefer the shorter implementation only when it keeps the same guarantees.
-- Run a final simplification pass before completion.
-- Update tests and docs whenever behavior contracts, public APIs, data shape, or UI contracts change.
-- When fixing a bug: append one sentence to the nearest relevant doc (`docs/flow-overview.md` or `docs/architecture-decision-record.md`) naming the root cause and how to prevent recurrence.
-
-For every meaningful change, explain:
-- what risk or friction existed
-- what changed
-- why the new shape is safer or easier to maintain
-```

package/.agent-context/prompts/review-code.md

@@ -1,31 +0,0 @@
-# Prompt: Review Code
-
-Use this when reviewing current changes, a pull request, or a focused file set.
-
-```text
-Review the code with a production-risk mindset.
-
-Before reviewing:
-1. Read AGENTS.md.
-2. Read .agent-context/review-checklists/pr-checklist.md.
-3. Read .agent-context/review-checklists/architecture-review.md only when architecture or boundaries changed.
-4. Load only the rules relevant to the changed scope.
-5. For UI changes, load .agent-context/prompts/bootstrap-design.md, .agent-context/rules/frontend-architecture.md, and docs/DESIGN.md when present.
-6. Enforce Universal SOP hard gate: block coding flow when required project docs are missing (root `README.md`; `docs/doc-index.md` when `docs/` exists; `docs/project-brief.md`; `docs/architecture-decision-record.md`; `docs/flow-overview.md`; `docs/database-schema.md` when persistent data exists; `docs/api-contract.md` when API or web application flows exist; and for UI scope `docs/DESIGN.md`).
-7. Enforce single-source and lazy-loading policy: canonical rule source must be explicitly enforced, global domain governance must load lazily based on touched scope, and conflicting duplicate rule instructions must not appear during normal flow.
-
-Prioritize findings in this order:
-1. Correctness, data loss, security, privacy, auth, and permission risks.
-2. Public contract drift: APIs, events, CLI behavior, data model, UI contract, docs.
-3. Missing tests for changed behavior.
-4. Architecture boundary drift and maintainability risk.
-5. Performance and accessibility issues with concrete impact.
-
-For every finding:
-- include file and line
-- explain the real risk
-- reference the rule or contract only when it materially supports the finding
-- propose the smallest safe fix
-
-Do not create stack-specific governance concerns. Use project framework details only for concrete implementation risks proven by changed code, docs, or current official documentation.
-```

package/.agent-context/review-checklists/architecture-review.md

@@ -1,57 +0,0 @@
-# Architecture Review Checklist
-
-Use this when module structure, feature shape, public contracts, topology, or refactoring are in scope.
-
-## Boundary Review
-
-- [ ] The changed code has clear transport, application, domain, and infrastructure boundaries where those layers exist.
-- [ ] Business policy is not hidden in transport handlers, UI adapters, database queries, framework glue, or generated code.
-- [ ] Controllers and route handlers only translate protocol input/output, enforce edge checks, and delegate business flow.
-- [ ] Service or use-case code owns orchestration, transactions, state transitions, and idempotency decisions.
-- [ ] Repository or adapter code owns persistence and external IO details without hiding product policy in queries.
-- [ ] Global backend/API governance is used directly; no stack-specific adapter or framework-specific rule fork was introduced.
-- [ ] Internal models do not leak across public API, event, CLI, library, or UI contracts without a deliberate mapping.
-- [ ] Modules import through public entrypoints instead of deep internal paths.
-- [ ] Circular dependencies are absent or explicitly removed.
-
-## Structure Review
-
-## Backend Universal Principles
-
-- [ ] No clever hacks in backend and shared core modules
-- [ ] No premature abstraction (base classes/util layers created only after repeated stable patterns)
-- [ ] Readability over brevity for maintainability
-- [ ] The project structure follows existing repo conventions unless a change was approved.
-- [ ] New structure is feature/domain-oriented when that improves discoverability.
-- [ ] Large files or modules are split around real responsibilities, not arbitrary layers.
-- [ ] Shared code is genuinely shared and not domain-specific behavior disguised as utility.
-- [ ] Names describe product meaning, not generic plumbing.
-
-## Topology Review
-
-- [ ] Monolith remains acceptable when boundaries, team size, consistency needs, and operations favor one deployable.
-- [ ] Service extraction is backed by current evidence: ownership, scaling, compliance, fault isolation, or deploy cadence.
-- [ ] Service boundaries define ownership, contract, data boundary, observability, timeouts, retry, and recovery behavior.
-- [ ] Event or realtime architecture is justified by product need, not trend pressure.
-
-## Contract Review
-
-- [ ] API, event, CLI, library, data, and UI contracts are documented before or alongside implementation.
-- [ ] Schema and validation strategy matches the project’s chosen runtime and official docs.
-- [ ] Error contracts are safe, stable, and do not leak internals.
-- [ ] List endpoints have bounded pagination, limits, or streaming behavior documented.
-- [ ] Sensitive mutations have documented idempotency, retry, and duplicate-submit behavior.
-- [ ] Error contracts document stable codes, safe trace or correlation identifiers, and any Problem Details-style fields when exposed.
-- [ ] Async/event contracts document retry, ordering, duplicate handling, and dead-letter or recovery behavior.
-- [ ] Migration and rollback plans exist for risky data or public contract changes.
-
-## Operational Review
-
-- [ ] Critical flows have tests at the right level.
-- [ ] Observability, logging, and health checks match the project’s runtime and risk level.
-- [ ] Security assumptions are documented and enforced at trust boundaries.
-- [ ] Performance-sensitive paths avoid avoidable repeated work, unbounded lists, and hidden blocking operations.
-- [ ] Relational reads avoid N+1 patterns or include an explicit query-shape rationale.
-- [ ] Multi-table or cross-resource writes are transactional or include a documented compensating recovery path.
-- [ ] Dual-write database plus message flows use an outbox or equivalent atomicity and replay strategy.
-- [ ] Cross-service consistency avoids default two-phase commit and defines saga, compensation, or recovery behavior when needed.

package/.agent-context/review-checklists/pr-checklist.md

@@ -1,134 +0,0 @@
-# PR Checklist - Quality Gate
-
-Run this before declaring a task done. Apply only the sections relevant to the changed scope, but do not skip correctness, security, testing, or docs checks when the change touches them.
-
-## 1. Repo Context
-
-- [ ] The agent read `AGENTS.md` and the smallest relevant rule set.
-- [ ] For non-trivial coding, review, planning, or governance work, the agent produced a Bootstrap Receipt with loaded files, selected rules, skipped rules, unreachable files, and validation plan before implementation output.
-- [ ] Risky actions used the AGENTS.md Bounded Reflection block with valid rule IDs, one-line rationale, and no copied rule prose or hidden chain-of-thought.
-- [ ] Existing project context came from real files, docs, package metadata, and changed code, not folder name alone.
-- [ ] Runtime, framework, library, topology, and design choices are explicit user constraints or agent recommendations from current evidence.
-- [ ] No offline default stack, blueprint, vendor, or visual style was treated as authoritative.
-
-## 2. Correctness
-
-- [ ] The changed behavior matches the user request.
-- [ ] Existing behavior is preserved unless the user approved a behavior change.
-- [ ] Edge cases, empty states, error paths, and rollback/recovery paths are handled.
-- [ ] Public contracts remain stable or are versioned and documented.
-
-## 3. Architecture
-### 2. Architecture (→ rules/architecture.md)
-- [ ] Layer and module boundaries are clear for the project’s chosen structure.
-- [ ] No clever hacks in backend and shared core modules
-- [ ] No premature abstraction (base classes/util layers created only after repeated stable patterns)
-- [ ] Readability over brevity for maintainability
-- [ ] Complexity budget was applied: equivalent behavior uses fewer moving parts without losing validation, error handling, fallbacks, accessibility, tests, or security boundaries.
-- [ ] Natural implementation pass was applied: the main flow is traceable, names are domain-specific, helpers carry real meaning, and compact code did not hide safeguards.
-- [ ] Controllers, route handlers, and transport adapters do not contain business policy, raw queries, or cross-resource orchestration.
-- [ ] Services or use cases own business flow, transaction boundaries, and mutation safety.
-- [ ] Repositories or adapters own persistence/external IO details without hiding business decisions.
-- [ ] Backend/API governance was applied through global domain rules, not stack-specific adapters or framework-only branches.
-- [ ] Code is grouped by feature/domain where that improves maintainability.
-- [ ] Cross-module access uses public contracts instead of internal file reach-through.
-- [ ] Files above roughly 1000 lines were split or explicitly justified.
-- [ ] Monolith/service split decisions are evidence-backed, not fashion-driven.
-
-## 4. Security And Privacy
-
-- [ ] External input is validated at trust boundaries using the project’s chosen validation approach.
-- [ ] Body, query, params, headers, cookies, uploads, webhooks, and job payloads are treated as untrusted until validated and normalized.
-- [ ] Secrets, tokens, credentials, and private data are not committed or logged.
-- [ ] Authorization is enforced at a trusted boundary.
-- [ ] Error responses and logs do not leak internals.
-- [ ] Least privilege, resource-level authorization, and secret handling are preserved where sensitive data or privileged actions are touched.
-- [ ] Dependency or platform security claims are based on current official docs or repo evidence.
-
-## 5. Testing
-
-- [ ] Changed behavior has appropriate tests at the smallest useful level.
-- [ ] API changes cover validation, authorization, documented error shape, pagination defaults, and empty states where relevant.
-- [ ] Sensitive mutations include idempotency or duplicate-submit coverage where duplicate side effects would be harmful.
-- [ ] Tests assert behavior and contracts, not implementation trivia.
-- [ ] Critical flows include failure-path coverage.
-- [ ] Test fixtures are readable and do not hide the behavior under test.
-
-## 6. Docs And Contracts
-
-### 10. Documentation
-
-- [ ] Scope applied: This applies to documentation, release notes, onboarding text, review summaries, and agent-facing explanations
-- [ ] Style scope review is advisory and does not block merge when API docs are synced in the same commit and contract details are correct
-- [ ] Required docs exist before implementation: public and developer root README; project brief; architecture decision; flow overview; API/public contract when relevant; data model when relevant; and UI design contract when relevant.
-- [ ] `docs/doc-index.md` exists whenever `docs/` exists and acts as a compact read-routing map instead of duplicating requirements or architecture.
-- [ ] For docs-only or docs-first requests, implementation code was not changed unless the user explicitly asked for it or approved an implementation plan.
-- [ ] Formal project docs use English by default unless the user requested another language or existing docs established one.
-- [ ] Docs cover feature plan, architecture rationale, public contracts, data model, UI/design, security assumptions, testing strategy, delivery flow, and next validation actions where relevant.
-- [ ] API, event, CLI, library, data, and UI contract changes update docs in the same scope.
-- [ ] Public surface changes fail review if documentation updates are missing or stale in the same scope
-- [ ] Documentation checks stay boundary-aware and only enforce touched scopes
-- [ ] Facts, assumptions, and next actions are separated when context is incomplete.
-- [ ] No emoji in formal documentation or review summaries
-- [ ] Documentation uses plain English and avoids AI cliches
-- [ ] Root README is public and developer friendly, even for private projects, and does not contain secrets, internal agent notes, private reasoning, or governance policy dumps.
-- [ ] Documentation grows with the project: README and matching docs were updated when setup, runtime, architecture, public contracts, data shape, deployment, validation, or UI scope changed.
-- [ ] Documentation file count stayed intentional: new docs files were added only for stable, distinct, or long workflows.
-- [ ] PRD, SRS, technical-design, or separate ERD files were added only when project evidence justified a distinct document.
-
-## 7. UI And Accessibility
-
-- [ ] UI work follows `docs/DESIGN.md`.
-- [ ] Visual direction is project-specific and not a template/default component-kit habit.
-- [ ] UI work includes a Motion/Palette Decision, and product categories were treated as heuristics rather than style presets.
-- [ ] Responsive behavior recomposes content and priority, not only shrinking desktop layout.
-- [ ] Accessibility hard requirements are preserved: keyboard access, focus visibility, contrast, target size, status feedback, and no color-only meaning.
-- [ ] Motion is treated as part of the design language for modern UI work, with reduced-motion and performance safeguards instead of defaulting to static screens.
-- [ ] Broad redesigns pass the old-design regression test: the result is not the previous composition with animation, depth, media, or interaction density removed.
-- [ ] UI work records an agent-chosen ambition level; broad screens and redesigns researched an expressive path first, and any downshift names a concrete blocker plus replacement interaction quality.
-- [ ] UI foundation choices are dynamic and product-fit; no shadcn, native-only, Tailwind-only, or component-kit default was selected by habit or avoided from dependency fear.
-- [ ] Design intent separates locked outcomes from flexible expression; candidate signature moves, exact token primitives, literal anchor artifacts, and component-kit skins were not treated as permanent requirements without evidence or user approval.
-
-## 8. Dependencies And Runtime
-
-- [ ] New dependencies are justified by capability, maintenance health, bundle/runtime cost, and current official docs.
-- [ ] Dependency avoidance was not treated as a default virtue; lightweight maintained libraries were considered when they improve correctness, accessibility, UX, maintainability, or delivery speed.
-- [ ] Official setup flows are preferred when they produce better-supported current defaults.
-- [ ] Docker, framework, package, and ecosystem claims were checked live when they could be stale.
-- [ ] Token optimization and memory continuity defaults remain enabled unless the user explicitly opts out.
-- [ ] If `.agent-context/state/active-memory.json` exists and the task made material project progress, the agent refreshed it directly before completion and preserved privacy/user-owned entries.
-
-## 9. State And Governance
-
-### 9.1 Context-Triggered Audit Mode
-
-- [ ] Strict audit mode activates automatically on review and PR-intent workflows
-- [ ] Small edits avoid heavy checks by default unless strict mode is explicitly requested
-- [ ] User can always force strict audit mode manually
-- [ ] Session handoff includes active architecture contract summary.
-- [ ] Drift detection warns before direction changes.
-- [ ] Direction changes require explicit user confirmation.
-- [ ] Default responses avoid unnecessary state-file internals.
-- [ ] State internals are exposed only on explicit request.
-- [ ] Diagnostic mode can explain relevant state decisions when needed.
-- [ ] Canonical rule source is explicitly defined and enforced
-- [ ] Global domain governance is loaded lazily based on touched scope
-- [ ] No conflicting duplicate rule instructions during normal flow
-- [ ] Canonical rule source is explicit and duplicate/conflicting instructions are avoided.
-
-### 15. Universal SOP Consolidation
-
-- [ ] `.agent-context/rules/` remains the default guidance source for implementation and review.
-- [ ] Security and testing requirements remain mandatory after static template purge.
-- [ ] Coding flow is blocked if `docs/project-brief.md` is missing
-- [ ] Coding flow is blocked if `docs/architecture-decision-record.md` (or `docs/Architecture-Decision-Record.md`) is missing
-- [ ] Coding flow is blocked if root `README.md` is missing
-- [ ] Coding flow is blocked if `docs/doc-index.md` is missing while `docs/` exists
-- [ ] Coding flow is blocked if `docs/flow-overview.md` is missing
-- [ ] Coding flow is blocked if `docs/database-schema.md` is missing while the project uses persistent data
-- [ ] Coding flow is blocked if `docs/api-contract.md` is missing while the project exposes API or web application flows
-- [ ] UI implementation flow is blocked if `docs/DESIGN.md` is missing
-
-## Verdict
-
-Report findings first, ordered by severity, with file/line references and concrete fixes. If no findings exist, say that explicitly and name any residual risk.

package/.agent-context/rules/api-docs.md

@@ -1,24 +0,0 @@
----
-id_prefix: API
-domain: api-docs
-priority: high
-scope: backend
-applies_to: [backend, fullstack]
-keywords: [api-docs, api, contract, documentation]
----
-
-# API Contract Boundary
-
-## API-001: Execution Rules
-1. Sync docs in the same commit when changing API, CLI, or schema.
-2. Root README.md is mandatory. Keep it overview-level. No secrets.
-3. Keep `docs/doc-index.md` as the routing map.
-4. Use OpenAPI 3.1 for HTTP APIs by default.
-5. Idempotency is mandatory for side-effect mutations (POST/PUT/PATCH).
-6. Use Mermaid.js natively for all diagrams. No PlantUML/D2.
-
-## API-002: Human Writing & Anti-Slop (Mandatory)
-1. NO EMOJI in any formal documentation, code, or review summaries. This is absolute.
-2. Use plain English and avoid generic AI cliches ("AI slop") in generated docs.
-3. Keep code clean and efficient. Do not write convoluted/long code if a shorter, efficient solution exists without losing functionality.
-4. Keep documentation short, clear, and directly actionable.

package/.agent-context/rules/api-versioning.md

@@ -1,16 +0,0 @@
----
-id_prefix: VER
-domain: api-versioning
-priority: medium
-scope: backend
-applies_to: [backend, fullstack]
-keywords: [api-versioning, versioning, deprecation]
----
-
-# API Versioning Boundary
-
-## VER-001: Execution Rules
-1. Never introduce breaking changes without versioning.
-2. Maintain backward compatibility.
-3. Use header-based or URL-path versioning explicitly.
-4. Document deprecation windows before sunsetting endpoints.