@ryuenn3123/agentic-senior-core 3.0.25 → 3.0.27

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

@@ -15,7 +15,7 @@ The agent must:
 2. If `docs/DESIGN.md` or `docs/design-intent.json` exists, refine them instead of replacing them blindly.
 3. If either design doc is missing, create it before UI implementation.
 4. Use current repo evidence, product copy, route names, component names, user goals, and existing constraints as the source of truth.
-5. Treat prior-chat visuals, unrelated project memory, benchmark screenshots, and famous-product aesthetics as tainted unless the user explicitly asks for continuity.
+5. Treat prior-chat visuals, unrelated project memory, benchmark screenshots, and famous-product aesthetics as tainted context unless the user explicitly asks for continuity.
 6. When choosing a new UI, animation, styling, or component library, research current official docs and choose the latest stable compatible option for this project. Do not rely on offline defaults.
 7. Keep external references non-copying: extract constraints and reasoning only, never clone the surface.
 
@@ -41,7 +41,7 @@ The final anchor must come from broad non-template domains such as complex physi
 
 Write the chosen anchor into `docs/design-intent.json` as `conceptualAnchor`, including agentResearchMode, sourceDomain, rationale, derivedTokenLogic, visualRiskBudget, motionRiskBudget, and cohesionChecks. Typography, spacing, density, color behavior, morphology, motion, and responsive composition must logically derive from that single anchor. If a later design choice does not follow from the anchor, revise the contract before coding.
 
-Motion is not a garnish. The agent may use rich animation, fluid transitions, spatial reveals, scroll choreography, micro-interactions, and modern motion libraries when they support the anchor, remain performant, and include reduced-motion fallbacks. Do not suppress motion merely to look safe.
+Motion is not a garnish. Default to a rich motion plan: fluid transitions, spatial reveals, scroll choreography, micro-interactions, and modern motion libraries are expected when they strengthen the anchor and product experience. Keep reduced-motion fallbacks instead of suppressing motion, and solve performance deliberately instead of using safety language as a reason to stay static.
 
 ## Zero-Based Redesign Protocol
 
@@ -62,7 +62,7 @@ The UI must feel authored by a strong UI/UX designer, not assembled from default
 Do:
 - Synthesize a visual direction from the project context and explain why it fits.
 - Choose color, typography, spacing, motion, density, and component morphology dynamically from the product and audience.
-- Use modern, expressive interaction when it improves hierarchy, feedback, delight, confidence, or memorability.
+- Use modern, expressive interaction and motion as part of the core design language, especially when it improves hierarchy, feedback, delight, confidence, or memorability.
 - Keep frontend code clean, componentized, accessible, and easy to maintain.
 - Use tokens and semantic aliases so future changes do not require rewriting components.
 - Make design decisions explicit before coding, then implement consistently.

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

@@ -13,6 +13,8 @@ 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 `docs/architecture-decision-record.md` is missing, and for UI scope stop if `docs/DESIGN.md` or `docs/design-intent.json` 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.
 
 Refactor rules:
 - Improve clarity, boundaries, naming, validation, error handling, tests, and docs.

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

@@ -12,7 +12,7 @@ Before reviewing:
 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, docs/DESIGN.md, and docs/design-intent.json when present.
 6. Enforce Universal SOP hard gate: block coding flow when required project docs are missing (`docs/architecture-decision-record.md`, and for UI scope `docs/DESIGN.md` plus `docs/design-intent.json`).
-7. Enforce single-source and lazy-loading policy: canonical rule source must be explicitly enforced, language-specific guidance must load lazily based on detected scope, and conflicting duplicate rule instructions must not appear during normal flow.
+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.
@@ -27,5 +27,5 @@ For every finding:
 - reference the rule or contract only when it materially supports the finding
 - propose the smallest safe fix
 
-Do not invent stack-specific concerns unless the repo or changed files prove they apply.
+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

@@ -6,6 +6,10 @@ Use this when module structure, feature shape, public contracts, topology, or re
 
 - [ ] 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.
@@ -35,6 +39,10 @@ Use this when module structure, feature shape, public contracts, topology, or re
 - [ ] 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
@@ -43,3 +51,7 @@ Use this when module structure, feature shape, public contracts, topology, or re
 - [ ] 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

@@ -24,6 +24,10 @@ Run this before declaring a task done. Apply only the sections relevant to the c
 - [ ] 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
+- [ ] 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.
@@ -32,14 +36,18 @@ Run this before declaring a task done. Apply only the sections relevant to the c
 ## 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.
@@ -65,7 +73,7 @@ Run this before declaring a task done. Apply only the sections relevant to the c
 - [ ] Visual direction is project-specific and not a template/default component-kit habit.
 - [ ] 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 purposeful, reduced-motion-safe, and justified by product value.
+- [ ] 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.
 
 ## 8. Dependencies And Runtime
 
@@ -88,7 +96,7 @@ Run this before declaring a task done. Apply only the sections relevant to the c
 - [ ] 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
-- [ ] Language-specific guidance is loaded lazily based on detected scope
+- [ ] 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.
 

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

@@ -9,6 +9,10 @@ If a change affects an API, CLI command, exported library behavior, schema, even
 - Document the public surface before or alongside implementation.
 - Machine-readable API contracts should use the current project standard. If unresolved, the LLM must recommend a current maintained option from official docs.
 - HTTP APIs should prefer OpenAPI 3.1 when no stronger project standard exists.
+- List endpoints must document pagination, limits, filtering, sorting, and empty-state behavior.
+- Sensitive mutation endpoints must document idempotency behavior, retry safety, duplicate-submit handling, and any required idempotency key or request fingerprint.
+- Public error contracts must document stable machine-readable codes and any RFC 9457 Problem Details-style fields the project exposes, including safe trace or correlation identifiers when present.
+- Async, webhook, and event contracts must document idempotency, retry, ordering, dead-letter or recovery behavior, and duplicate-message handling.
 - Event APIs should define producer, consumer, payload, versioning, retry, and failure behavior.
 - CLI/library public behavior must update README, help text, changelog, or docs as appropriate.
 - Do not write "see code" as the contract.

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

@@ -50,9 +50,9 @@ The `.agent-context/rules/` directory is the default guidance source for impleme
 
 - Canonical rule source is .instructions.md.
 - Adapter entry files stay thin and must point to the canonical source.
-- Load language-specific stack guidance lazily based on detected scope.
-- Load language-specific or framework-specific guidance lazily based on changed files, explicit constraints, and repo evidence.
-- Do not preload unrelated stack profiles during normal flow.
+- Load global domain rules lazily based on touched scope.
+- Do not create or load stack-specific governance adapters as the baseline.
+- Runtime or framework evidence can clarify implementation details, but it must not replace the global architecture, security, data, API, error, event, and testing boundaries.
 - Keep rule-loading output deterministic for init and release validation.
 
 ## Architecture Decision Boundary

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

@@ -10,4 +10,13 @@ Reject these bad habits:
 - raw query construction that bypasses safe parameterization
 - destructive data changes without backup, migration, or deployment sequencing notes
 
+Backend data access rules:
+- Relational reads must avoid N+1 query patterns. Use eager loading, joins, batching, or explicit query-shape rationale based on the project's ORM or database driver.
+- List endpoints and exports must paginate, limit, stream, or otherwise bound growable datasets by default.
+- Use cursor pagination for large or frequently changing datasets when the project contract allows it; offset pagination is acceptable for small, stable, explicitly bounded collections.
+- Define maximum page size, payload size, and export limits so list responses cannot exhaust memory or connection pools.
+- Mutations that write more than one table, aggregate, queue, or external consistency boundary must run inside a transaction or document the compensating recovery path.
+- Repository and data-access layers own persistence mechanics. They must not hide business policy that belongs in application or domain logic.
+- Cross-domain persistence must respect ownership boundaries. Independent services must not share database tables as an integration contract; modular monoliths may share one database only when module ownership and access paths stay explicit.
+
 Docs must record entity ownership, relationships, constraints, data lifecycle, migration risk, and assumptions to validate.

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

@@ -9,4 +9,12 @@ Reject these failure patterns:
 - retries without transient-failure evidence, limits, backoff, and a clear final outcome
 - logs that say only "something failed" without action, target, actor, or trace context
 
+Backend API error rules:
+- Use the framework's normal centralized error boundary or middleware for HTTP/API responses.
+- Do not return raw exception messages, stack traces, SQL, provider payloads, file paths, secrets, or infrastructure details to callers.
+- Public API errors must use a stable JSON shape with at least `code` and `message`; include `details` only when the data is safe, documented, and useful to the caller. HTTP APIs may use an RFC 9457 Problem Details-style shape when it fits the project contract.
+- Domain and validation errors should keep machine-readable codes so tests, clients, and operators can distinguish expected failures from defects.
+- API boundary errors should include a safe correlation or trace identifier when observability exists, while protected logs keep the internal exception, actor, target, and trace context.
+- Distributed systems should preserve trace context across ingress and egress using the project's tracing standard, such as W3C Trace Context or OpenTelemetry propagation.
+
 At boundaries, validate early, return safe user-facing errors, and keep machine-readable error context for operators and callers.

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

@@ -17,6 +17,9 @@ Hard rules:
 - consumers are idempotent
 - retries are bounded and dead-letter or recovery behavior is defined
 - transactional publishing uses an outbox or equivalent safety pattern when data consistency matters
+- dual-write flows that update local state and publish a message must use a transactional outbox or document an equivalent atomicity and replay strategy
+- distributed transactions and two-phase commit are not the default recovery model; prefer local transactions plus saga, choreography, orchestration, or explicit compensating actions when consistency crosses service boundaries
+- message handlers must record processed message identifiers or use another duplicate-detection strategy when the delivery model can retry or redeliver
 - event catalogs or docs identify producer, consumers, ownership, and schema evolution rules
 
 If event tooling is unresolved, the LLM must recommend a current project-fit broker or managed service from official docs before implementation.

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

@@ -58,7 +58,7 @@ Do not use this file to teach generic frontend basics the model already knows.
 - Before UI code, choose one agent-synthesized conceptual anchor from high-variance non-software domains and record only the final anchor in `docs/design-intent.json`.
 - Internally reject the safest dashboard, portal, card-grid, admin-shell, or minimalist-web-app mental model before writing CSS.
 - Typography, spacing, morphology, motion, and responsive recomposition must derive from the chosen anchor, not from framework defaults.
-- Rich motion, spatial transitions, and micro-interactions are allowed when they support the anchor and include reduced-motion and performance safeguards.
+- Default to an expressive motion plan derived from the anchor. Use spatial transitions, micro-interactions, scroll choreography, and modern animation libraries when they improve the experience; include reduced-motion and performance safeguards without using them as an excuse for a static UI.
 
 ## Responsive Mutation Requirements
 
@@ -72,7 +72,7 @@ Do not use this file to teach generic frontend basics the model already knows.
 - Define the primary user task or reading path from current evidence before arranging surfaces.
 - Supporting surfaces must earn their placement through role, priority, or behavior. They must not feel like cloned modules.
 - Component states must preserve identity under hover, focus, loading, success, empty, and error. Do not let everything collapse into anonymous rounded panels.
-- Motion may be expressive, but it must strengthen hierarchy, feedback, or memorability while staying reduced-motion-safe and performant.
+- Motion should be expressive by default for modern UI work. Make it strengthen hierarchy, feedback, or memorability, then keep it reduced-motion-safe and performant.
 
 ## Implementation Boundaries
 

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

@@ -35,7 +35,9 @@ Hard rules:
 - Each service owns its data boundary.
 - Public service contracts must be documented before implementation or extraction.
 - Cross-service calls need timeout, retry, idempotency, observability, and recovery behavior.
+- Independent services must not use shared tables as their integration contract; communicate through documented APIs, events, or async workflows owned by the source domain.
 - Avoid synchronous call chains that turn services into a distributed monolith.
+- Critical cross-service mutations should prefer local transactions plus outbox, saga, choreography, orchestration, or compensating actions over two-phase commit by default.
 - Prefer incremental extraction over rewrites.
 
 If the evidence is unclear, document the uncertainty and keep the topology agent-recommended instead of pretending an offline default is correct.

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

@@ -10,5 +10,16 @@ Hard rules:
 - enforce authorization at the server or trusted boundary, not only in UI state
 - return safe client-facing errors and keep sensitive detail in protected logs
 - document auth, permission, data exposure, rate-limit, and abuse assumptions before changing sensitive flows
+- apply least privilege to service accounts, API tokens, database users, background jobs, and operator/admin actions
+- retrieve secrets through environment, runtime secret injection, or the project's secret manager; do not store static secrets in source or plaintext config
+- keep `.env` and local secret files covered by `.gitignore`; commit only safe examples such as `.env.example`
+- treat transport encryption, secure cookies, and trusted proxy boundaries as deployment assumptions that must be documented when sensitive traffic is involved
+
+Zero-trust API input rules:
+- Treat body, query, params, headers, cookies, uploaded files, webhook payloads, and background job payloads as untrusted until validated.
+- Validate and normalize input at the outer boundary before it reaches service, use-case, repository, or domain logic.
+- Services should receive typed, already-validated values and still enforce domain invariants for security-sensitive rules.
+- Sanitization must match the sink: SQL, shell, file path, log, HTML, template, and URL contexts need different protections.
+- Authorization must be resource-aware when data ownership matters. Prefer row, tenant, account, organization, or resource-level checks over role-only checks for sensitive records.
 
 For high-risk changes, check current framework security docs and record the relevant source or assumption in the implementation notes.

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

@@ -8,6 +8,14 @@ Test what can break:
 - regressions around bugs being fixed
 - critical accessibility or responsive behavior when UI is in scope
 
+Backend/API test rules:
+- API tests must cover request validation, authorization boundaries, success responses, documented error shapes, pagination defaults, and empty states for touched endpoints.
+- Sensitive mutations such as payments, orders, status changes, inventory adjustments, and account/security changes must include duplicate-submit or retry tests when idempotency is required.
+- Data-access changes must include evidence for query shape, transaction behavior, rollback or recovery paths, and N+1 prevention when relational reads are touched.
+- Event or worker changes must test retry, duplicate-message handling, dead-letter or recovery behavior, and outbox relay semantics when those paths exist.
+- Distributed consistency changes must test the local transaction, publish/retry behavior, and compensating action or recovery path rather than only the happy path.
+- Tests should make the API contract obvious from the fixture names, inputs, and expected response shape.
+
 Do not test framework internals, third-party library behavior, private implementation trivia, or snapshots that only freeze noise.
 
 Tests should describe behavior, keep setup readable, and mock only at real boundaries such as network, filesystem, clock, database, or external services.

package/.agent-context/state/memory-continuity-benchmark.json

@@ -1,5 +1,5 @@
 {
-  "generatedAt": "2026-04-24T17:20:37.769Z",
+  "generatedAt": "2026-04-25T10:16:51.159Z",
   "reportName": "memory-continuity-benchmark",
   "schemaVersion": "1.0.0",
   "passed": true,

package/.agent-context/state/weekly-governance-report.json

@@ -1,16 +1,27 @@
 {
-  "generatedAt": "2026-04-11T12:21:37.776Z",
+  "generatedAt": "2026-04-25T09:59:20.980Z",
   "reportName": "weekly-governance-report",
   "methodology": {
     "qualityTrendSource": "state-file",
     "qualityTrendGeneratedAt": "2026-04-11T12:21:35.779Z",
     "commitWindowDays": 7,
     "requiredVerifiedDomains": [
-      "cli",
-      "frontend",
-      "fullstack",
-      "distribution",
-      "review-quality"
+      "canonical-instructions",
+      "frontend-design-contract",
+      "frontend-architecture",
+      "backend-architecture",
+      "backend-security",
+      "backend-data-access",
+      "backend-error-handling",
+      "backend-api-contract",
+      "backend-testing",
+      "backend-performance",
+      "backend-idempotency",
+      "backend-risk-map",
+      "pr-checklist",
+      "architecture-review",
+      "mcp-server",
+      "state-continuity"
     ]
   },
   "qualitySignals": {
@@ -31,64 +42,236 @@
   "skillTrust": {
     "domains": [
       {
-        "domain": "backend",
-        "tier": "experimental",
-        "score": 25
+        "domain": "architecture-review",
+        "tier": "verified",
+        "score": 100,
+        "sourcePath": ".agent-context/review-checklists/architecture-review.md"
+      },
+      {
+        "domain": "backend-api-contract",
+        "tier": "verified",
+        "score": 100,
+        "sourcePath": ".agent-context/rules/api-docs.md"
+      },
+      {
+        "domain": "backend-architecture",
+        "tier": "verified",
+        "score": 100,
+        "sourcePath": ".agent-context/rules/architecture.md"
+      },
+      {
+        "domain": "backend-data-access",
+        "tier": "verified",
+        "score": 100,
+        "sourcePath": ".agent-context/rules/database-design.md"
+      },
+      {
+        "domain": "backend-error-handling",
+        "tier": "verified",
+        "score": 100,
+        "sourcePath": ".agent-context/rules/error-handling.md"
+      },
+      {
+        "domain": "backend-idempotency",
+        "tier": "verified",
+        "score": 100,
+        "sourcePath": ".agent-context/rules/event-driven.md"
       },
       {
-        "domain": "cli",
+        "domain": "backend-performance",
         "tier": "verified",
-        "score": 100
+        "score": 100,
+        "sourcePath": ".agent-context/rules/performance.md"
       },
       {
-        "domain": "distribution",
+        "domain": "backend-risk-map",
         "tier": "verified",
-        "score": 100
+        "score": 100,
+        "sourcePath": ".agent-context/state/architecture-map.md"
       },
       {
-        "domain": "frontend",
+        "domain": "backend-security",
         "tier": "verified",
-        "score": 100
+        "score": 100,
+        "sourcePath": ".agent-context/rules/security.md"
       },
       {
-        "domain": "fullstack",
+        "domain": "backend-testing",
         "tier": "verified",
-        "score": 100
+        "score": 100,
+        "sourcePath": ".agent-context/rules/testing.md"
       },
       {
-        "domain": "review-quality",
+        "domain": "canonical-instructions",
         "tier": "verified",
-        "score": 100
+        "score": 100,
+        "sourcePath": ".instructions.md"
+      },
+      {
+        "domain": "frontend-architecture",
+        "tier": "verified",
+        "score": 100,
+        "sourcePath": ".agent-context/rules/frontend-architecture.md"
+      },
+      {
+        "domain": "frontend-design-contract",
+        "tier": "verified",
+        "score": 100,
+        "sourcePath": ".agent-context/prompts/bootstrap-design.md"
+      },
+      {
+        "domain": "mcp-server",
+        "tier": "verified",
+        "score": 100,
+        "sourcePath": "scripts/mcp-server.mjs"
+      },
+      {
+        "domain": "pr-checklist",
+        "tier": "verified",
+        "score": 100,
+        "sourcePath": ".agent-context/review-checklists/pr-checklist.md"
+      },
+      {
+        "domain": "state-continuity",
+        "tier": "verified",
+        "score": 100,
+        "sourcePath": ".agent-context/state"
       }
     ],
     "tierCounts": {
-      "verified": 5,
+      "verified": 16,
       "community": 0,
-      "experimental": 1
+      "experimental": 0
     },
     "requiredVerifiedDomains": [
-      "cli",
-      "frontend",
-      "fullstack",
-      "distribution",
-      "review-quality"
+      "canonical-instructions",
+      "frontend-design-contract",
+      "frontend-architecture",
+      "backend-architecture",
+      "backend-security",
+      "backend-data-access",
+      "backend-error-handling",
+      "backend-api-contract",
+      "backend-testing",
+      "backend-performance",
+      "backend-idempotency",
+      "backend-risk-map",
+      "pr-checklist",
+      "architecture-review",
+      "mcp-server",
+      "state-continuity"
     ],
     "requiredVerifiedDomainFailures": [],
     "allRequiredVerified": true
   },
+  "backendGovernance": {
+    "status": "verified",
+    "summary": "Backend governance is verified across architecture, security, data access, error handling, API contracts, testing, performance, idempotency, and risk-map surfaces.",
+    "requiredSurfaceCount": 9,
+    "verifiedSurfaceCount": 9,
+    "missingSurfaceNames": [],
+    "coverage": [
+      {
+        "constraint": "Layered architecture and separation of concerns",
+        "status": "covered",
+        "sourcePaths": [
+          ".agent-context/rules/architecture.md",
+          ".agent-context/review-checklists/architecture-review.md"
+        ],
+        "signal": "Transport, application, domain, and infrastructure boundaries are explicit."
+      },
+      {
+        "constraint": "Global backend/API rule routing",
+        "status": "strengthened",
+        "sourcePaths": [
+          ".instructions.md",
+          ".agent-context/rules/architecture.md",
+          ".agent-context/prompts/refactor.md"
+        ],
+        "signal": "Backend/API governance routes by problem domain and stays stack-agnostic; no stack-specific governance adapters are created."
+      },
+      {
+        "constraint": "Zero-trust input validation",
+        "status": "strengthened",
+        "sourcePaths": [
+          ".agent-context/rules/security.md",
+          ".agent-context/review-checklists/pr-checklist.md"
+        ],
+        "signal": "User-controlled body, query, params, headers, cookies, files, webhooks, and job payloads must be validated before service logic."
+      },
+      {
+        "constraint": "Data access performance and integrity",
+        "status": "strengthened",
+        "sourcePaths": [
+          ".agent-context/rules/database-design.md",
+          ".agent-context/rules/performance.md",
+          ".agent-context/state/architecture-map.md"
+        ],
+        "signal": "Backend reads must avoid N+1 and unbounded list responses; multi-write mutations need transaction or recovery evidence."
+      },
+      {
+        "constraint": "Distributed consistency and outbox safety",
+        "status": "strengthened",
+        "sourcePaths": [
+          ".agent-context/rules/event-driven.md",
+          ".agent-context/rules/database-design.md",
+          ".agent-context/rules/microservices.md"
+        ],
+        "signal": "Dual-write flows need outbox or equivalent replay safety, and cross-service consistency must define saga, compensation, or recovery behavior instead of defaulting to two-phase commit."
+      },
+      {
+        "constraint": "Safe centralized API errors",
+        "status": "strengthened",
+        "sourcePaths": [
+          ".agent-context/rules/error-handling.md",
+          ".agent-context/rules/api-docs.md"
+        ],
+        "signal": "HTTP/API responses use safe machine-readable error shapes, may align with RFC 9457 Problem Details, and preserve safe trace/correlation identifiers without leaking internals."
+      },
+      {
+        "constraint": "Sensitive mutation idempotency",
+        "status": "strengthened",
+        "sourcePaths": [
+          ".agent-context/rules/api-docs.md",
+          ".agent-context/rules/testing.md",
+          ".agent-context/rules/event-driven.md"
+        ],
+        "signal": "Payments, orders, status changes, and other risky mutations must document and test duplicate-submit behavior."
+      },
+      {
+        "constraint": "API contract and behavior testing",
+        "status": "strengthened",
+        "sourcePaths": [
+          ".agent-context/rules/testing.md",
+          ".agent-context/review-checklists/pr-checklist.md"
+        ],
+        "signal": "API tests cover validation, auth, documented error shapes, pagination defaults, empty states, and mutation retry safety."
+      }
+    ],
+    "developmentFocus": [
+      {
+        "focus": "Keep backend guidance global and stack-agnostic.",
+        "reason": "The repo should enforce architecture, security, API, data, error, event, and testing thinking without building Nest, Laravel, FastAPI, Express, Go, or other stack-specific governance adapters."
+      },
+      {
+        "focus": "Use framework facts only when implementing inside an existing project.",
+        "reason": "LLMs can apply current ecosystem knowledge directly; governance should route the relevant global constraints instead of acting as a stack detector."
+      }
+    ]
+  },
   "commitSignals": {
     "windowDays": 7,
-    "commitCount": 18,
-    "releaseCommitCount": 7,
+    "commitCount": 30,
+    "releaseCommitCount": 18,
     "rollbackCommitCount": 1,
-    "releaseFrequencyPercent": 38.89,
-    "rollbackFrequencyPercent": 5.56,
+    "releaseFrequencyPercent": 60,
+    "rollbackFrequencyPercent": 3.33,
     "error": null
   },
   "releaseReadiness": {
     "isReady": true,
     "blockers": [],
-    "summary": "Weekly governance posture is ready for maintenance releases."
+    "summary": "Weekly governance posture is ready for maintenance releases with frontend and backend governance surfaces verified."
   },
   "artifact": {
     "path": "E:\\Project\\Agentic-Senior-Core\\.agent-context\\state\\weekly-governance-report.json",
@@ -121,6 +304,26 @@
       "verifiedSkillDomainCount": 5,
       "releaseFrequencyPercent": 38.89,
       "rollbackFrequencyPercent": 5.56
+    },
+    {
+      "generatedAt": "2026-04-25T06:41:17.654Z",
+      "readinessStatus": "ready",
+      "blockerCount": 0,
+      "gatePassRatePercent": 100,
+      "verifiedSkillDomainCount": 16,
+      "backendVerifiedSurfaceCount": 9,
+      "releaseFrequencyPercent": 60,
+      "rollbackFrequencyPercent": 3.33
+    },
+    {
+      "generatedAt": "2026-04-25T09:59:20.980Z",
+      "readinessStatus": "ready",
+      "blockerCount": 0,
+      "gatePassRatePercent": 100,
+      "verifiedSkillDomainCount": 16,
+      "backendVerifiedSurfaceCount": 9,
+      "releaseFrequencyPercent": 60,
+      "rollbackFrequencyPercent": 3.33
     }
   ]
 }

package/.cursorrules

@@ -1,6 +1,6 @@
 # AGENTIC-SENIOR-CORE DYNAMIC GOVERNANCE RULESET
 
-Generated by Agentic-Senior-Core CLI v3.0.25
+Generated by Agentic-Senior-Core CLI v3.0.27
 Timestamp: 2026-04-24T06:02:48.303Z
 Selected policy file: .agent-context/policies/llm-judge-threshold.json
 

package/.gemini/instructions.md

@@ -2,7 +2,7 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: e6984d32169e98e32c9e6b6d6209bb2613b63b22d1e66af63a70788be00c55d5
+Canonical Snapshot SHA256: 11eeafb3ff6a0977785e3668a704c6bba543b515d2828c02de8276f6cf1c391c
 
 Canonical policy source: [.instructions.md](../.instructions.md).
 
@@ -10,6 +10,7 @@ If your host stops at this file, follow this minimum floor:
 - Read `.agent-instructions.md` next when it exists.
 - For UI or redesign requests, load [.agent-context/prompts/bootstrap-design.md](../.agent-context/prompts/bootstrap-design.md) and [.agent-context/rules/frontend-architecture.md](../.agent-context/rules/frontend-architecture.md) before coding.
 - If UI scope and `docs/DESIGN.md` or `docs/design-intent.json` is missing, materialize them before UI implementation.
+- For backend/API/data/auth/event requests, load relevant global rules from [.agent-context/rules/](../.agent-context/rules) and do not create stack-specific governance adapters.
 - Memory continuity is host-dependent project memory and does not replace bootstrap loading.
 
 ## Bootstrap Sequence
@@ -20,7 +21,7 @@ If your host stops at this file, follow this minimum floor:
 4. Load request templates from [.agent-context/prompts/](../.agent-context/prompts).
 5. Apply review contracts from [.agent-context/review-checklists/](../.agent-context/review-checklists).
 6. Apply state awareness from [.agent-context/state/](../.agent-context/state) and policy thresholds from [.agent-context/policies/](../.agent-context/policies).
-7. Resolve stack, structure, and dependency choices from project context docs plus live evidence.
+7. Resolve runtime, structure, and dependency choices from project context docs plus live evidence.
 
 ## Completion Gate