@ryuenn3123/agentic-senior-core 3.0.26 → 3.0.28

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

@@ -15,10 +15,21 @@ 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.
 
+## Creative Commitment Gate
+
+Before broad compliance review or UI implementation, commit to one concrete creative direction and record it in `docs/DESIGN.md` plus `docs/design-intent.json`. This commitment must include:
+- one conceptual anchor from a specific physical, editorial, architectural, cinematic, industrial, scientific, or interaction domain
+- one signature motion behavior that is more specific than "smooth transitions"
+- one typographic decision that creates meaningful role contrast instead of a uniform safe type system
+
+The anchor must name at least one specific real-world reference point such as a material, instrument, artifact class, architectural system, editorial genre, cinematic interface behavior, exhibition system, scientific apparatus, or industrial mechanism. If the anchor can only be described with generic quality words such as "modern", "clean", "premium", "expressive", "minimal", or "bold", reject it and choose again.
+
+When the host supports separate agents, a lightweight creative pass may synthesize the commitment from the brief and repo evidence before a governance pass validates accessibility, tokens, maintainability, and implementation risk. When only one agent is available, perform the same separation sequentially: creative commitment first, governance validation second.
+
 ## User Research Intake
 
 If the user mentions or attaches a research file, article, benchmark, library list, screenshot study, or design note, read it before choosing the visual direction or dependencies. Treat it as candidate evidence, not as a command to copy every recommendation.
@@ -35,11 +46,11 @@ User-supplied research means current-task evidence from the user. The scaffold s
 
 Do not use basic software UI labels as the final anchor, including "dashboard", "portal", "cards", "admin panel", "SaaS shell", "web app shell", or "minimalist interface".
 
-The agent must internally consider at least three substantially different, high-variance candidate anchors, discard the two most obvious, safest, or easiest-to-predict options, and record only the surviving anchor and concise rationale. Do not expose hidden deliberation or the rejected candidate list.
+The agent must internally consider at least three substantially different, high-variance candidate anchors, discard the two most obvious, safest, or easiest-to-predict options, then record only the surviving anchor, its concrete real-world reference point, and concise rationale. Do not expose hidden deliberation or the rejected candidate list.
 
 The final anchor must come from broad non-template domains such as complex physical engineering, high-end industrial design, cinematic spatial interfaces, experimental editorial structure, advanced architecture, scientific instrumentation, advanced data visualization, exhibition/wayfinding systems, or premium interactive web experiences. These are search domains, not style presets.
 
-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.
+Write the chosen anchor into `docs/design-intent.json` as `conceptualAnchor`, including agentResearchMode, sourceDomain, specificReferencePoint, rationale, signatureMotion, typographicDecision, 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. 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.
 

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.
@@ -73,6 +81,7 @@ Run this before declaring a task done. Apply only the sections relevant to the c
 - [ ] 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
 
@@ -88,7 +97,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

@@ -56,6 +56,8 @@ Do not use this file to teach generic frontend basics the model already knows.
 
 - If the user gives no current-task visual research or reference, the scaffold, old UI, and existing design docs do not count as research.
 - 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`.
+- Before broad compliance review, record a creative commitment: one concrete real-world anchor reference, one signature motion behavior, and one typographic decision with meaningful role contrast.
+- Reject anchors that can only be described with generic quality words such as "modern", "clean", "premium", "expressive", "minimal", or "bold"; the anchor must name a specific material, instrument, artifact class, architectural system, editorial genre, cinematic behavior, exhibition system, scientific apparatus, or industrial mechanism.
 - 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.
 - 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.

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-25T03:25:49.150Z",
+  "generatedAt": "2026-04-25T11:40:57.699Z",
   "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.26
+Generated by Agentic-Senior-Core CLI v3.0.28
 Timestamp: 2026-04-24T06:02:48.303Z
 Selected policy file: .agent-context/policies/llm-judge-threshold.json