@ryuenn3123/agentic-senior-core 4.3.15 → 5.1.0

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,136 +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
-
-### 11. 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.

package/.agent-context/rules/architecture.md

@@ -1,33 +0,0 @@
----
-id_prefix: ARCH
-domain: architecture
-priority: critical
-scope: all-tasks
-applies_to: [backend, frontend, fullstack]
-keywords: [architecture, arch, boundary, system]
----
-
-# Architecture Boundary
-
-## ARCH-001: Execution Rules
-1. Rely on ESLint/Linters for structural enforcement.
-2. Require README.md and docs/doc-index.md.
-3. Run `npm run validate` to enforce architecture invariants.
-4. Do not invent custom crypto, custom state management, or custom routing. Use standard libraries.
-
-## ARCH-005: Rules as Guardian (Cross-Session Consistency)
-1. Session handoff must include active architecture contract summary.
-2. Detect drift before changing runtime choices, topology, public contracts, or core patterns.
-3. Direction changes require explicit user confirmation before applying changes.
-
-## ARCH-006: Invisible State Management with Explain-on-Demand
-1. Default responses must avoid unnecessary state-file internals.
-2. State internals are exposed only on explicit user request.
-3. Diagnostic mode explains relevant state decisions when needed.
-
-## ARCH-007: Single Source of Truth and Lazy Rule Loading
-1. Canonical rule source is AGENTS.md.
-2. Load global domain rules lazily based on touched scope.
-3. Do not create or load stack-specific governance adapters as the baseline.
-
-

package/.agent-context/rules/background-jobs.md

@@ -1,17 +0,0 @@
----
-id_prefix: JOB
-domain: background-jobs
-priority: medium
-scope: backend
-applies_to: [backend, fullstack]
-keywords: [background-jobs, worker, cron, queue]
----
-
-# Background Jobs Boundary
-
-## JOB-001: Execution Rules
-1. All jobs must be idempotent.
-2. Offload heavy processing (>500ms) to background queues.
-3. Use dead-letter queues (DLQ) for failed jobs.
-4. Emit telemetry on job failure/success.
-5. Jobs must have timeouts and retry limits.

package/.agent-context/rules/config-and-flags.md

@@ -1,16 +0,0 @@
----
-id_prefix: CFG
-domain: config-and-flags
-priority: high
-scope: backend
-applies_to: [backend, frontend, fullstack]
-keywords: [configuration, feature-flags, environment, secrets]
----
-
-# Configuration Boundary
-
-## CFG-001: Execution Rules
-1. Inject secrets via environment variables.
-2. Never store secrets in code. Use .env.example for templates.
-3. Use feature flags for incremental rollouts.
-4. Validate config shapes at startup. Fail fast if invalid.

package/.agent-context/rules/database-design.md

@@ -1,18 +0,0 @@
----
-id_prefix: DATA
-domain: database-design
-priority: high
-scope: data
-applies_to: [backend, fullstack]
-keywords: [database-design, data, schema]
----
-
-# Data Design Boundary
-
-## DATA-001: Execution Rules
-1. Avoid N+1 queries. Use eager loading or batching.
-2. Paginate growable datasets.
-3. Multi-table mutations must run inside transactions.
-4. Monetary amounts must be integer (minor units) or exact decimal. NO floats.
-5. Store real-world timestamps in UTC. NO naive timestamps.
-6. Use optimistic concurrency tokens (ETag/version) for shared mutable resources.

package/.agent-context/rules/docker-runtime.md

@@ -1,17 +0,0 @@
----
-id_prefix: DOCK
-domain: docker-runtime
-priority: high
-scope: infra
-applies_to: [backend, frontend, fullstack]
-keywords: [docker-runtime, docker, runtime]
----
-
-# Docker Runtime Boundary
-
-## DOCK-001: Execution Rules
-1. ALWAYS perform Live Research / Web Search for latest official Docker documentation before writing configuration.
-2. Keep Dev and Prod stages separate.
-3. Use minimal trusted base images. Avoid running as root in Prod.
-4. Never bake secrets into image layers.
-5. Define explicit healthchecks in production compose files.

package/.agent-context/rules/error-handling.md

@@ -1,16 +0,0 @@
----
-id_prefix: ERR
-domain: error-handling
-priority: high
-scope: backend
-applies_to: [backend, frontend, fullstack]
-keywords: [error-handling, errors, exception]
----
-
-# Error Handling Boundary
-
-## ERR-001: Execution Rules
-1. Fail fast on invalid input.
-2. Do not leak stack traces to clients. Log them securely.
-3. Use standardized machine-readable error codes (RFC 9457).
-4. Distinguish client errors (4xx) from server errors (5xx).

package/.agent-context/rules/event-driven.md

@@ -1,16 +0,0 @@
----
-id_prefix: EVT
-domain: event-driven
-priority: medium
-scope: backend
-applies_to: [backend, fullstack]
-keywords: [event-driven, events, kafka, rabbitmq]
----
-
-# Event Driven Boundary
-
-## EVT-001: Execution Rules
-1. Events must be immutable.
-2. Consumers must be idempotent.
-3. Handle out-of-order events securely.
-4. Always implement Dead Letter Queues (DLQ) for poison messages.

package/.agent-context/rules/frontend-architecture.md

@@ -1,54 +0,0 @@
----
-id_prefix: FE
-domain: frontend-architecture
-priority: high
-scope: ui
-last_validated: 2026-05-17
-applies_to: [frontend, fullstack]
-keywords: [frontend-architecture, fe, ui, engineering]
----
-
-# Frontend Engineering Invariants (Tier 2)
-
-Load this rule for UI-facing engineering work. This file contains strict engineering constraints.
-
-## FE-009: Accessibility
-1. WCAG 2.2 AA is the hard floor. APCA is advisory perceptual tuning only.
-2. Hard checks: focus visibility, target size, keyboard access, color-only meaning.
-
-## FE-010: CSS Production Hardening
-1. Plan overflow, wrapping, truncation, empty, loading, and error behavior.
-2. Prefer logical composition primitives (container queries, subgrid).
-
-## FE-011: Implementation Boundaries
-1. Follow the shipped project stack and current repo patterns.
-2. Do not hardcode framework-specific state management or data fetching libraries, or rigid component doctrines.
-
-## FE-012: Data State Surface
-1. Explicitly handle empty, loading, error, and offline states.
-2. Reject "spinner everywhere".
-
-## FE-013: Background and Wallpaper Discipline
-1. Decorative geometry are invalid as wallpaper.
-2. Use grids/lines only for specific functional roles (alignment, map, crop).
-
-## FE-014: Production Content Policy
-1. No visible testing, demo, sample, placeholder, lorem, or TODO labels in production UI.
-
-## FE-015: Motion Implementation Budget
-1. Keep reduced-motion, keyboard, loading, performance, and mobile fallbacks explicit.
-
-## FE-016: Library and Design-Intent Discipline
-1. Use component kits or headless primitives for behavior and accessibility when they fit.
-
-## FE-017: Interactivity Priority
-1. The interactive boundary must be drawn deliberately. Keep client-side state boundaries small.
-2. Measure responsiveness through Interaction to Next Paint (INP).
-
-## FE-018: Internationalization as Layout
-1. Direction-sensitive spacing, alignment, and positioning must use CSS logical properties (e.g., `margin-inline-start`).
-2. Plan a documented text-expansion budget for target locales.
-
-## FE-019: Theme as Context
-1. A theme switch is a change in lighting and surface model, not a color inversion. Re-derive tokens per theme.
-2. Brand colors carried across themes must be individually verified against the active theme's contrast floor.

package/.agent-context/rules/microservices.md

@@ -1,16 +0,0 @@
----
-id_prefix: SVC
-domain: microservices
-priority: medium
-scope: backend
-applies_to: [backend, fullstack]
-keywords: [microservices, monolith]
----
-
-# Microservices Boundary
-
-## SVC-001: Execution Rules
-1. Default to modular monoliths unless scale explicitly dictates microservices.
-2. Independent services must own their data. NO shared databases.
-3. Cross-service calls must have timeouts and retries.
-4. Prefer async choreographies over distributed two-phase commits.

package/.agent-context/rules/migrations.md

@@ -1,16 +0,0 @@
----
-id_prefix: MIG
-domain: migrations
-priority: high
-scope: data
-applies_to: [backend, fullstack]
-keywords: [migrations, schema, database]
----
-
-# Migrations Boundary
-
-## MIG-001: Execution Rules
-1. Schema changes MUST have a versioned migration.
-2. Migrations must be reversible (down-migrations) or have a recovery plan.
-3. Never modify past migrations once merged. Create a new one.
-4. Use concurrent index builds in production.

package/.agent-context/rules/observability.md

@@ -1,16 +0,0 @@
----
-id_prefix: OBS
-domain: observability
-priority: high
-scope: backend
-applies_to: [backend, fullstack]
-keywords: [observability, telemetry, logs, metrics]
----
-
-# Observability Boundary
-
-## OBS-001: Execution Rules
-1. Emit telemetry for failures, degraded states, and security events.
-2. Inject correlation IDs on inbound requests and propagate them downstream.
-3. Do not log PII, secrets, or credentials.
-4. Measure latency, traffic, errors, and saturation.

package/.agent-context/rules/performance.md

@@ -1,16 +0,0 @@
----
-id_prefix: PERF
-domain: performance
-priority: medium
-scope: backend
-applies_to: [backend, frontend, fullstack]
-keywords: [performance, perf, optimization]
----
-
-# Performance Boundary
-
-## PERF-001: Execution Rules
-1. Optimize DB queries before adding caches.
-2. Compress network payloads.
-3. Bound memory usage (paginate, stream). No unbounded arrays.
-4. Cache aggressively but define explicit cache invalidation.

package/.agent-context/rules/realtime.md

@@ -1,16 +0,0 @@
----
-id_prefix: RT
-domain: realtime
-priority: medium
-scope: backend
-applies_to: [backend, fullstack]
-keywords: [realtime, websockets, sse]
----
-
-# Realtime Boundary
-
-## RT-001: Execution Rules
-1. Use SSE for one-way server-to-client streams. Use WebSockets only for true bi-directional.
-2. Realtime connections must gracefully degrade to polling if blocked.
-3. Implement ping/pong heartbeats to drop dead connections.
-4. Scale pub/sub via Redis or dedicated brokers.

package/.agent-context/rules/resilience.md

@@ -1,18 +0,0 @@
----
-id_prefix: RES
-domain: resilience
-priority: critical
-scope: backend
-applies_to: [backend, fullstack]
-keywords: [resilience, timeout, retry]
----
-
-# Resilience Boundary
-
-## RES-001: Execution Rules
-1. Every outbound network call MUST have a strict timeout.
-2. Retries MUST use exponential backoff with jitter and max attempt limits.
-3. Only retry idempotent operations.
-4. Fail fast using Circuit Breakers / Load Shedding on unhealthy dependencies.
-5. Provide graceful degradation on non-critical dependency failures.
-6. Enforce backpressure on bounded consumers.

package/.agent-context/rules/security.md

@@ -1,18 +0,0 @@
----
-id_prefix: SEC
-domain: security
-priority: critical
-scope: all-tasks
-applies_to: [backend, frontend, fullstack]
-keywords: [security, boundary, zero-trust]
----
-
-# Security Boundary
-
-## SEC-001: Execution Rules
-1. Validate and normalize ALL inputs.
-2. Parameterize all SQL queries. Never interpolate input into DB or Shell.
-3. Hash passwords with Argon2/Bcrypt. NEVER store plain text or use MD5/SHA.
-4. NEVER commit secrets, tokens, or credentials.
-5. Implement resource-aware authorization (Row-Level), not just Authentication.
-6. Verify service-to-service cryptographic identity.

package/.agent-context/rules/testing.md

@@ -1,16 +0,0 @@
----
-id_prefix: TEST
-domain: testing
-priority: medium
-scope: all-tasks
-applies_to: [backend, frontend, fullstack]
-keywords: [testing, tests, coverage]
----
-
-# Testing Boundary
-
-## TEST-001: Execution Rules
-1. Write tests for business logic and boundary failures.
-2. Test error states, not just the happy path.
-3. Use deterministic mocks for external services.
-4. Ensure CI pipelines block on test failures.

package/.agent-context/state/README.md

@@ -1,25 +0,0 @@
-# State Artifacts
-
-Use this directory as a typed governance state surface, not as a dump folder.
-
-Tracked seed/config artifacts:
-- `architecture-map.md`
-- `dependency-map.md`
-- `benchmark-comparison-schema.json`
-- `benchmark-reproducibility.json`
-- `benchmark-thresholds.json`
-- `benchmark-writer-judge-config.json`
-- `memory-adapter-contract.json`
-- `memory-schema-v1.json`
-
-Tracked operational artifact:
-- `onboarding-report.json` stays tracked in this repository because internal audits read it as the current repository onboarding state. In installed projects, `init` and `upgrade` regenerate this file.
-
-Local-only/generated artifacts:
-- `active-memory.json`
-- `llm-judge-report.json`
-- `token-saver/`
-- `token-optimization-report.json`
-- benchmark, trend, weekly governance, and quality report outputs
-
-Do not treat generated reports or archived research as current project truth. Rerun the matching `npm run benchmark:*`, `npm run report:*`, or `npm run audit:*` command when fresh evidence is needed.