@ryuenn3123/agentic-senior-core 4.0.3 → 4.2.0

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

@@ -0,0 +1,84 @@
+---
+id_prefix: MIG
+domain: migrations
+priority: critical
+scope: data
+last_validated: 2026-05-17
+applies_to:
+  - backend
+  - fullstack
+keywords:
+  - migrations
+  - schema
+  - ddl
+  - expand-contract
+  - backfill
+  - rollback
+---
+
+# Migrations Boundary
+
+A schema or data-shape change that touches live traffic is a deployment with two moving parts: the schema and the code that depends on it. Migrations safety is the property that the user-facing operation continues to succeed during, and after, the change, regardless of which side ships first or which side rolls back. Vendor-specific online-migration tools that may appear in commentary are illustrative; the authority is the safety invariants below.
+
+## MIG-001: Hard rules (Mandatory)
+
+1. Every schema change that touches live data must be decomposed into expansion steps (additive, non-breaking, independently deployable) and contraction steps (removal of old structures), with at least one production deployment between phases. Single-step schema changes that simultaneously add and remove are forbidden on hot data.
+2. The deploy ordering invariant must hold across the entire migration: code that requires the new schema must not deploy before the migration that introduces it, and code that requires the old schema must not deploy after the migration that removes it. The ordering must be documented in the migration ticket and verified by the deploy procedure.
+3. A migration must be reversible, or it must carry a documented forward-only recovery plan. "We will figure it out" is not a recovery plan.
+4. Reject migrations that lack a rollback or recovery plan. Reject deploy procedures that allow a code revert to land while the schema is still in the new shape, or vice versa, without an explicit compensating step.
+
+## MIG-002: Lock posture (Mandatory)
+
+1. Any DDL operation expected to hold an exclusive or share lock for longer than the service's acceptable request-latency threshold must use the platform's online or non-blocking migration mechanism. The threshold is the service's own latency budget, not a fixed number of rows or a fixed wall-clock duration.
+2. Where the platform supports a two-phase mechanism for constraints (for example, validate-without-lock followed by an asynchronous validate, or platform-equivalent concurrent index creation), use it instead of a single locking statement. The implementation must record which phase is run in which deploy.
+3. Long-running statements must run with an explicit statement timeout or lock-wait timeout, so a stuck DDL cannot hold a global lock indefinitely.
+4. Reject DDL inside long-running transactions that also contain unrelated work. Reject foreign-key or check-constraint additions on hot tables in a single locking statement when the platform offers a non-blocking variant.
+
+## MIG-003: Backfills (Mandatory)
+
+1. Backfills are separate from DDL. The DDL adds the column, table, or index in its safe shape (nullable, no-default, or non-unique, as appropriate); the backfill populates or repairs data in idempotent, resumable batches.
+2. A backfill job must be idempotent: rerunning the job, including from an arbitrary mid-progress checkpoint, must converge to the same final state without double-writing or double-charging.
+3. A backfill job must be resumable. The job must record progress on a durable cursor so a process restart, deploy, or worker rotation does not require restarting from the beginning.
+4. A backfill job must be observable. It must emit progress, throughput, and error-rate telemetry; an operator must be able to answer "how far has the backfill progressed?" without reading the data store directly.
+5. A backfill job must be throttleable. It must respect the platform's load on the source data store, and an operator must be able to slow or pause it during incidents without losing progress.
+6. Reject "backfill in the migration script". Reject backfill jobs that do not record progress, that cannot be paused, or that have no completion criterion.
+
+## MIG-004: Risk documentation (Mandatory)
+
+Every migration ticket or change record must capture, at change time, the following:
+
+1. Estimated runtime on production-equivalent data volume.
+2. Lock posture: which locks the operation acquires, on which objects, for how long, and which queries it will block.
+3. Data volume estimate: rows or bytes touched.
+4. Rollback plan or, if forward-only, the recovery plan with explicit data-loss exposure.
+5. Deploy-ordering note: which application version range is safe with the old schema, which with the new, and which with both. Both-compatible windows are required for any change that touches a request path.
+6. Backfill plan, if any: what data is rewritten, in what batch shape, with what idempotency key.
+7. Verification step: the post-migration check the operator runs to confirm the schema, the data, and the application all match the intended end state.
+
+A change that ships without these fields is not a migration; it is a defect waiting to happen.
+
+## MIG-005: Boundary safety (Mandatory)
+
+1. Cross-service migrations must coordinate the schema change with the downstream consumers. A producer that drops a field before downstream consumers stop reading it is a breaking change disguised as a migration.
+2. Event payload schemas, message contracts, and shared cache shapes are subject to the same expand-contract discipline as relational schemas. Producers add the new shape first, consumers learn to read both, then producers retire the old shape.
+3. Reject "we control all consumers" as a substitute for the expand-contract discipline; consumers include retried events from before the deploy, mobile clients with stale code, and parallel-running canaries.
+
+## MIG-006: Reject these bad habits
+
+1. Reject one-shot DDL that adds and removes structures in the same deploy on hot data.
+2. Reject migrations that take an exclusive lock on a hot table without a non-blocking alternative tested first.
+3. Reject backfills baked into the migration transaction so the transaction cannot complete in time.
+4. Reject "feature-flag the schema" patterns where two code paths read or write incompatible shapes against the same column without an explicit migration plan.
+5. Reject migration tickets that omit the risk-documentation fields above.
+6. Reject claims of reversibility that are not actually exercised on a non-production environment before production deploy.
+
+## MIG-007: Citations and freshness
+
+Authority sources for the rules in this file:
+
+- The expand-contract or parallel-change pattern in mainstream continuous-delivery and database-refactoring literature: authority for the multi-phase deploy discipline.
+- Database engine documentation for the platform in use: authority for which DDL operations are non-blocking, which require a rewrite, which acquire what locks, and which support a two-phase validate. Verify the platform's current major-version documentation at audit time, because lock posture changes between major versions of the same engine.
+- IETF RFC 7807 and successor problem-detail specifications: authority for how a write that hits a deploy-ordering window should communicate its rejection to the caller.
+
+Vendor-specific online-migration tools (in any database ecosystem) are illustrative implementations of the lock-posture and backfill rules above; they are not authority. Use the platform-appropriate mechanism that exists in the deployed engine version.
+<!-- DURABILITY CHECK: Rule relies exclusively on architectural invariants and relative operational thresholds. Valid beyond standard tooling lifecycles. -->

package/.agent-context/rules/naming-conv.md

@@ -27,6 +27,9 @@ Use the target language and framework conventions. Do not invent a naming style
 3. Reject names that require reading the implementation to understand the value.
 4. Keep file and directory naming styles consistent inside the same feature unless a framework reason requires mixed styles.
 5. Reject booleans, units, and side-effect functions whose names hide what they represent or change.
-6. Inline comments must explain why, not what.
-7. Put a one-line rationale near non-obvious choices that deserve explanation, such as retry strategy, index column order, denormalized field, intentional swallow with named recovery, or magic constant tied to an external system.
-8. Treat comments that paraphrase the code as noise.
+6. Name collections as collections when the language convention supports it.
+7. Name side-effect functions with an action plus the domain outcome they change.
+8. Avoid broad function names that describe activity without domain intent.
+9. Inline comments must explain why, not what.
+10. Put a one-line rationale near non-obvious choices that deserve explanation, such as retry strategy, index column order, denormalized field, intentional swallow with named recovery, or magic constant tied to an external system.
+11. Treat comments that paraphrase the code as noise.

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

@@ -0,0 +1,69 @@
+---
+id_prefix: OBS
+domain: observability
+priority: high
+scope: backend
+last_validated: 2026-05-17
+applies_to:
+  - backend
+  - fullstack
+keywords:
+  - observability
+  - telemetry
+  - logs
+  - metrics
+  - traces
+  - slo
+  - alerts
+---
+
+# Observability Boundary
+
+Observability is the property of a system that lets an operator answer, after the fact, which user, which code path, and which dependency caused a given outcome, using signals captured at runtime. Treat metrics, logs, and traces as derived views over structured per-request events; the underlying obligation is that the captured events are enough to reconstruct what happened, regardless of which storage shape a vendor calls a "pillar".
+
+## OBS-001: Hard rules (Mandatory)
+
+1. Every request, job, and message-handler invocation must emit a structured event that carries: a stable request or correlation identifier, the operation name, the upstream caller identity, the downstream dependencies it touched, the outcome status, and the duration. The event payload must be machine-parseable, not a free-text log line.
+2. Trace context must propagate across every in-process and cross-process boundary the system controls. The system must not drop or rewrite an inbound trace identifier; it must extend it.
+3. Logs, metrics, and traces must share the same correlation identifier so an operator can pivot between them without manual joining.
+4. Configuration of telemetry destinations, sampling rates, and log levels must come from runtime configuration; the system must not require a code change to redirect signals or to raise verbosity during an incident.
+5. The system must redact or omit secrets, tokens, full request and response bodies, and personal data from logs, metric labels, span attributes, and error reports. Identifiers, counts, sizes, and shapes are acceptable.
+6. The system must expose a documented health surface that distinguishes liveness, readiness, and startup where the runtime supports it. A `200 OK` that does not check critical dependencies is not a readiness signal.
+
+## OBS-002: Reject these bad habits
+
+1. Reject metric label cardinality that is unbounded by design. User identifiers, request identifiers, full URLs, raw query strings, and session identifiers must not be metric labels; they belong in event attributes that the storage tier can index without exploding cardinality.
+2. Reject vendor-proprietary instrumentation when an open standard provides equivalent coverage. Where the platform supports it, prefer instrumentation that exports through W3C Trace Context and OpenTelemetry semantic conventions so the backend storage choice can change without re-instrumenting the application.
+3. Reject substituting one signal for another. Do not parse free-text logs to derive metrics that should have been recorded as metrics. Do not search free-text logs to reconstruct call graphs that should have been recorded as traces. Each signal type carries different sampling, retention, and indexing trade-offs; collapsing them hides those trade-offs.
+4. Reject logging of full request bodies, headers containing authorization material, raw uploads, decrypted secrets, plaintext tokens, and direct personal identifiers. A log line that would leak a credential if forwarded to a third-party storage provider is a defect.
+5. Reject paging humans for symptoms that have no documented user impact. Do not page on raw resource utilization, on a single failed request, or on a single retry; page on a sustained breach of a documented service-level objective whose error budget has been spent.
+6. Reject "happy-path-only" telemetry. Error paths, retries, fallbacks, throttles, circuit transitions, and degraded-mode fallbacks must emit events of equal or higher fidelity than the success path; a system that is loud only when healthy is observable only when it is fine.
+7. Reject silent drops. The telemetry pipeline itself must report when it sheds events, drops spans, or rate-limits log output, so an operator can distinguish "no events" from "events lost".
+
+## OBS-003: SLOs and alerts (Mandatory)
+
+1. Every alert that pages a human must be backed by a documented service-level objective expressed in user-facing terms (availability of a journey, latency of a critical interaction, freshness of a derived dataset). Alerts without an SLO and an explicit error-budget intent are noise.
+2. SLO definitions must record: the user journey or contract being measured, the success criterion (status, latency threshold, freshness threshold), the measurement window, the target attainment, and the agreed action when the error budget burns at an elevated rate.
+3. Multi-window, multi-burn-rate alerting (or platform equivalent) is preferred so a fast burn pages quickly without amplifying flapping on slow burns. Single-threshold alerting on a raw counter is acceptable only when no error budget can be defined for the signal.
+4. Alert routing must distinguish actionable alerts (paged human required to recover the user journey) from informational alerts (record-only, dashboard-only). Pager rotations must not receive informational alerts.
+5. Telemetry retention windows must cover at least one full SLO measurement window plus the longest documented incident-investigation window the team commits to.
+6. Reject alerts whose runbook is "investigate the dashboard". Every actionable alert needs a documented next step that a non-author on-call can execute.
+
+## OBS-004: Audit and forensics (Mandatory)
+
+1. Security-relevant events (authentication outcomes, authorization decisions, privilege changes, data exports, configuration changes, key rotations) must be emitted on a separate, append-only event stream with stricter retention and access controls than operational telemetry.
+2. Audit events must record: who acted, what was acted upon, when, from which network identity, and the outcome. Source identity must come from the authenticated principal, not from a self-reported value in the request body.
+3. Audit-event storage must remain readable when the application's primary database is unavailable, or the audit event must be considered untrustworthy.
+4. Reject mixing audit events into the same low-retention, broadly readable channel as operational logs.
+
+## OBS-005: Citations and freshness
+
+Authority sources for the rules in this file:
+
+- W3C Trace Context (W3C Recommendation): the canonical contract for propagating `traceparent` and `tracestate` across boundaries. Verify the current Recommendation when authoring instrumentation that crosses an organizational boundary.
+- OpenTelemetry semantic conventions: the open-standard set of attribute names for traces, metrics, and logs across HTTP, RPC, messaging, and database operations. Use the version current at audit time; older fixed snapshots drift.
+- RFC 5424 (The Syslog Protocol): authority for severity ordering when mapping log levels onto a transport that requires it.
+- OWASP ASVS: requirements for security-relevant audit logging, including the events listed above as audit-stream candidates.
+
+These citations are illustrative anchors, not vendor endorsements. Vendor names that may appear in commentary (for example, the names of trace backends, log aggregators, or APM products) are not authority for this rule.
+<!-- DURABILITY CHECK: Rule relies exclusively on architectural invariants and relative operational thresholds. Valid beyond standard tooling lifecycles. -->

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

@@ -0,0 +1,78 @@
+---
+id_prefix: RES
+domain: resilience
+priority: critical
+scope: backend
+last_validated: 2026-05-17
+applies_to:
+  - backend
+  - fullstack
+keywords:
+  - resilience
+  - timeout
+  - retry
+  - deadline
+  - degradation
+  - backpressure
+---
+
+# Resilience Boundary
+
+The system must remain useful when a dependency is slow, partial, or unavailable. Resilience is the property that the user-facing operation either completes within an agreed budget, fails fast with a clear outcome, or runs in a documented degraded mode; it is not the absence of failure. Vendor names and library names that may appear in commentary (timeout libraries, service meshes, adaptive-concurrency runtimes) are not authority for this rule.
+
+## RES-001: Timeouts and deadlines (Mandatory)
+
+1. Every outbound network or inter-process call must carry an explicit timeout derived from the user-facing operation's worst-acceptable latency. Library defaults and "no timeout" are not acceptable.
+2. The timeout must be smaller than the upstream caller's remaining latency budget. A request handler that has 800 ms of remaining budget must not issue a downstream call configured to wait 5 seconds.
+3. The system must propagate the caller's remaining deadline downstream so a downstream operation cannot continue past the upstream's expiration. If the platform exposes a deadline header or a context cancellation primitive, use it; otherwise, transmit the remaining budget as an explicit field on the call.
+4. Connect, read, and idle timeouts must be set independently. A combined "request timeout" that hides which phase exceeded the budget makes failure analysis ambiguous.
+5. Reject reliance on default timeouts. Reject "infinite" or platform-maximum timeouts on user-facing call paths. Reject configuring a downstream timeout larger than the upstream caller's remaining budget.
+
+## RES-002: Retries (Mandatory)
+
+1. Retries are allowed only on operations that are idempotent on the target, or on operations that carry an idempotency identifier the target honors within a documented retention window.
+2. Retries must use exponential backoff with jitter and a documented attempt cap. Fixed-interval retries are forbidden because they synchronize callers during incidents.
+3. Each retry must inherit the caller's remaining deadline; the sum of attempts plus backoff must not exceed the original budget.
+4. Retries must distinguish retriable failures (transient network, explicit retry-after, documented `5xx` semantics) from non-retriable failures (validation, authorization, business-rule rejection); non-retriable failures must surface immediately without consuming retry budget.
+5. Reject retries on non-idempotent writes that lack an idempotency identifier on the target. Reject retry storms: any pattern where many callers retry on the same schedule, without jitter, and without a global cap, is a defect even if each caller is locally well-behaved.
+
+## RES-003: Failing fast on unhealthy dependencies (Mandatory)
+
+1. When a dependency's failure rate, latency, or queue depth indicates it cannot serve traffic within the user-facing latency budget, the calling component must shed load on that dependency rather than continue to issue calls that will time out.
+2. Load shedding is an outcome, not a named pattern. The system may achieve it through any mechanism appropriate to the platform: a service mesh fault-tolerance policy, an adaptive-concurrency limiter, an in-process state machine that rejects calls during a recovery window, or a rate limiter informed by health probes. Choose what the platform supports; do not write a custom mechanism when the platform provides one.
+3. The shedding component must emit a telemetry event when it transitions between healthy, degraded, and shedding states, so an operator can correlate user impact with the decision to shed.
+4. The shedding component must have a documented recovery path: how it re-admits traffic to the dependency, how it confirms the dependency is healthy, and how it bounds the rate of recovery to avoid a thundering herd.
+5. Reject open-loop retry behavior against an upstream that has been unhealthy for longer than its documented recovery window. Reject "fail open" defaults on security-relevant calls (authorization, license enforcement); those must fail closed and the user-facing impact must be a documented degraded mode, not silent permission.
+
+## RES-004: Dependency isolation (Mandatory)
+
+1. Independent dependencies must use independent resource pools (connection pools, thread pools, semaphore quotas, or platform-equivalent admission control) so the saturation of one upstream cannot exhaust the pools used by another.
+2. The size of each pool must be derived from the dependency's documented capacity and the caller's latency budget, not from a default.
+3. The system must expose the in-flight count, the queue depth, and the rejection count for each pool as telemetry, so an operator can distinguish "dependency slow" from "caller's pool exhausted".
+4. Reject sharing one global pool across unrelated downstream calls when the platform supports separation. Reject silent unbounded queueing in front of a saturated pool; bounded queues with explicit rejection are mandatory.
+
+## RES-005: Graceful degradation (Mandatory)
+
+1. For each dependency, the implementation must answer one question explicitly in code or in a runbook: "what does the caller still do for the user when this dependency is unavailable?" A generic catch-all error response is not an answer.
+2. Acceptable degraded behaviors include: serving a cached or older version of the data with a freshness indicator, returning a partial result with the unavailable section labelled as such, queueing the request for later processing with a documented user-visible acknowledgement, or refusing the operation with a clear error that names the unavailable subsystem.
+3. The user-facing error path must distinguish "we cannot do this right now, retry later" from "we will not do this, do not retry"; clients reading these responses act differently on the two.
+4. Degraded behavior must be observable: a request served from a fallback path must emit telemetry that records which fallback fired, why, and how stale or partial the result was.
+5. Reject silent degradation. A response that hides a fallback from the caller, or that omits a stale-data marker when the data is stale, is a defect.
+
+## RES-006: Backpressure across producers and consumers (Mandatory)
+
+1. Any boundary between an unbounded producer (user requests, upstream events, ingestion stream) and a bounded consumer must apply backpressure: shed load, throttle the producer, or expose lag back to the producer. Silent unbounded growth of an in-memory or on-disk queue is forbidden.
+2. The boundary must expose its current lag, drop rate, and rejection reason as telemetry, so an operator can choose between scaling the consumer, slowing the producer, or shedding low-value traffic.
+3. Reject "queue grows until OOM" as an acceptable failure mode. Reject "we will scale later" as a substitute for explicit backpressure on a path that already takes user traffic.
+
+## RES-007: Citations and freshness
+
+Authority and background reading for the rules in this file:
+
+- AWS Well-Architected Framework, Reliability Pillar (REL05 and surrounding controls): authority on dependency isolation, timeouts, retries with backoff, and graceful degradation as deployment-architecture concerns. Verify against the Reliability Pillar version current at audit time.
+- Google SRE Workbook chapters on overload and addressing cascading failures: background reading on load shedding, graceful degradation, and the difference between transient and persistent failure modes.
+- IETF RFC 7231 and successor specifications for HTTP semantics: authority for which response statuses are safe to retry by default.
+- IETF RFC 7234 and `Retry-After` semantics: authority for cooperating with explicit retry-control signals from upstreams.
+
+Vendor-specific resilience libraries (circuit-breaker libraries, service-mesh fault-tolerance modules, language-runtime cancellation primitives) are illustrative implementations of the outcomes above; they are not authority. Choose the implementation appropriate to the platform.
+<!-- DURABILITY CHECK: Rule relies exclusively on architectural invariants and relative operational thresholds. Valid beyond standard tooling lifecycles. -->

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

@@ -3,6 +3,7 @@ id_prefix: SEC
 domain: security
 priority: critical
 scope: all-tasks
+last_validated: 2026-05-17
 applies_to:
   - backend
   - frontend
@@ -43,3 +44,30 @@ Use the security model and libraries already present in the project. If security
 4. Sanitization must match the sink: SQL, shell, file path, log, HTML, template, and URL contexts need different protections.
 5. 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.
 6. For high-risk changes, check current framework security docs and record the relevant source or assumption in the implementation notes.
+
+## SEC-003: Authentication versus authorization
+
+1. Authentication proves identity (this caller is who they claim to be); authorization grants capability (this identity may perform this action on this resource). The two are different concerns and must be implemented as distinct layers.
+2. Request-handling code must not conflate them. A handler that checks "is this caller logged in?" and treats the answer as permission to mutate the resource is a defect, regardless of how strong the authentication check is.
+3. The authorization decision layer must be independently testable from the request-handling layer. The system must support tests that pass an authenticated principal plus a target resource and a requested action and assert the decision, without standing up the full HTTP transport.
+4. Authorization decisions must be recorded as audit events [REF:OBS-004]: who acted, what was acted upon, the requested action, and the decision. A "permitted" decision and a "denied" decision both belong on the audit stream.
+5. Reject controllers that mix authentication checks, business policy, and persistence in one block. Reject role-only authorization on resources that have owners; ownership-, tenant-, or relationship-aware authorization is required when records have owners.
+
+## SEC-004: Credential storage
+
+1. Passwords and other reversible-equivalent credentials must be hashed with a memory-hard, computationally-tunable algorithm intended for password storage. Argon2id is the current widely accepted default; bcrypt remains acceptable on platforms where a memory-hard implementation is unavailable or on platforms where the operational surface has already standardized on it. The mechanism must be tunable: as hardware improves, the work factor must be raised without a code change.
+2. General-purpose hash functions (MD5, SHA-1, SHA-256, SHA-3 by themselves) are forbidden for password storage. They are designed to be fast; password storage requires a function designed to be slow under attacker hardware.
+3. Stored credentials must include a per-credential random salt at the size and shape the chosen algorithm specifies; global pepper, if used, must come from the secret manager [REF:CFG-002], not from source.
+4. Verification must be constant-time for the comparison step where the platform supports it, to limit timing-side-channel inference about partial matches.
+5. Credential rotation must be supported as a runtime operation: the system must be able to re-hash a credential at the next successful authentication when the work factor or algorithm changes, without forcing a coordinated reset.
+6. Reject storing credentials with a general-purpose hash. Reject storing credentials in plaintext for any reason, including "for support recovery". Reject pinning a work factor that the platform's hardware has outpaced; the work factor is a tuning parameter, not a constant.
+
+## SEC-005: Service-to-service authentication
+
+1. Service-to-service identity must be cryptographically verifiable at the receiving end. Acceptable mechanisms include mutual TLS with verified peer certificates, OIDC client-credentials flow with short-lived tokens, signed bearer tokens with a documented issuer and verifiable signature, or platform-equivalent verifiable identity (workload identity, signed JWT-over-mTLS).
+2. Tokens used between services must carry a short time-to-live (the value depends on the platform's revocation latency and the operation's blast radius; record the chosen TTL and the rationale, do not inherit a default).
+3. The receiving service must validate the token's issuer, signature, audience, expiration, and not-before fields on every request. A cached "yes this is valid" decision that bypasses signature validation is a defect.
+4. Reject shared static tokens (a single long-lived API key embedded in every caller) as the sole identity mechanism between services. Static tokens are acceptable only as one factor inside a stronger mechanism, or as a deliberate fallback for narrowly-scoped, audit-logged emergency access.
+5. Reject IP-allow-list as a substitute for cryptographic identity on networks the producer does not exclusively control. Reject "trusted network" as a substitute for verifying the caller; zero-trust is the default at the service boundary.
+6. Authority for the rules above includes OWASP ASVS sections on authentication and session management, IETF RFC 6749 (OAuth 2.0) and successors for token-based identity, and the platform's current workload-identity documentation. Verify the current versions at audit time.
+<!-- DURABILITY CHECK: Rule relies exclusively on architectural invariants and relative operational thresholds. Valid beyond standard tooling lifecycles. -->

package/AGENTS.md

@@ -18,7 +18,7 @@ Write instructions as imperative gates:
 - Add validation when a rule can drift.
 
 ## Bootstrap Receipt
-For non-trivial coding, review, planning, or governance work, emit a concise Bootstrap Receipt before implementation output or file edits:
+For non-trivial coding, review, planning, or governance work, run `agentic-senior-core context` first if available, or `npx @ryuenn3123/agentic-senior-core context` when only the package is available, then emit a concise Bootstrap Receipt before implementation output or file edits:
 - `loaded_files`: files actually read
 - `selected_rules`: files selected for this scope and why
 - `skipped_rules`: out-of-scope categories left unloaded
@@ -28,24 +28,24 @@ For non-trivial coding, review, planning, or governance work, emit a concise Boo
 Keep it short. Do not load every rule just to fill it out.
 
 ## Command Economy
-Avoid repeated command output. Do not rerun broad inspections unless edits changed the result. Prefer targeted reads, targeted searches, concise diffs, and final validation gates.
+Avoid repeated command output. Do not rerun broad inspections unless edits changed the result. Prefer targeted reads, concise diffs, and `ascx git status` / `ascx git diff` / `ascx npm test` when available; use raw commands for pipes, redirects, or unsupported commands.
 
 ## Layer Index
-### Layer 1: Rules (15 Files) [SCOPE-RESOLVED]
+### Layer 1: Rules (21 Files) [SCOPE-RESOLVED]
 Location: `.agent-context/rules/`.
 
 Load only relevant rule files. Do not read the entire rule directory by default.
 
-Available rules: `naming-conv.md` (`NAME-*`, v4), `architecture.md` (`ARCH-*`, v4), `security.md` (`SEC-*`, v4), `performance.md` (`PERF-*`, v4), `error-handling.md` (`ERR-*`, v4), `testing.md` (`TEST-*`, v4), `git-workflow.md` (`GIT-*`, v4), `efficiency-vs-hype.md` (`DEP-*`, v4), `api-docs.md` (`API-*`, v4), `microservices.md` (`SVC-*`, v4), `event-driven.md` (`EVT-*`, v4), `database-design.md` (`DATA-*`, v4), `realtime.md` (`RT-*`, v4), `frontend-architecture.md` (`FE-*`, v4), `docker-runtime.md` (`DOCK-*`, v4).
+Available rules: `naming-conv.md` (`NAME-*`, v4), `architecture.md` (`ARCH-*`, v4), `security.md` (`SEC-*`, v4), `performance.md` (`PERF-*`, v4), `error-handling.md` (`ERR-*`, v4), `testing.md` (`TEST-*`, v4), `git-workflow.md` (`GIT-*`, v4), `efficiency-vs-hype.md` (`DEP-*`, v4), `api-docs.md` (`API-*`, v4), `microservices.md` (`SVC-*`, v4), `event-driven.md` (`EVT-*`, v4), `database-design.md` (`DATA-*`, v4), `realtime.md` (`RT-*`, v4), `frontend-architecture.md` (`FE-*`, v4), `docker-runtime.md` (`DOCK-*`, v4), `observability.md` (`OBS-*`, v4), `resilience.md` (`RES-*`, v4), `migrations.md` (`MIG-*`, v4), `background-jobs.md` (`JOB-*`, v4), `config-and-flags.md` (`CFG-*`, v4), `api-versioning.md` (`VER-*`, v4).
 
-For Docker or Compose work, load `docker-runtime.md` and verify the latest official Docker docs before authoring container assets. Also perform live web research for Docker and framework/package setup claims. For framework or package setup work, use the latest stable compatible dependency set and official setup flow unless a documented compatibility constraint blocks it. Prefer official framework scaffolders when they create the supported project shape; manual file assembly needs a repo, prototype, learning, or architecture reason. New dependencies are allowed when they improve efficiency, delivery time, correctness, accessibility, UX, or maintainability. Do not treat dependency avoidance or vague performance fear as a default reason to skip a modern maintained library.
+For Docker or Compose work, load `docker-runtime.md` and verify the latest official Docker docs before authoring container assets. Also perform live web research for Docker and framework/package setup claims. For framework or package setup work, use the latest stable compatible dependency set and official setup flow unless a documented compatibility constraint blocks it; prefer official framework scaffolders when they create the supported project shape. New dependencies are allowed when they improve efficiency, delivery time, correctness, accessibility, UX, or maintainability. Do not treat dependency avoidance or vague performance fear as a default reason to skip a modern maintained library.
 
 Backend/API routing:
-- Data/schema/persistence: `architecture.md`, `database-design.md`, `performance.md`, `testing.md`.
-- Endpoint/API/error contracts: `architecture.md`, `api-docs.md`, `error-handling.md`, `security.md`, `testing.md`.
-- Auth/secrets/uploads/permissions: `security.md`, `error-handling.md`, `testing.md`.
-- Queue/worker/cron/events/retry: `event-driven.md`, `database-design.md`, `error-handling.md`, `performance.md`, `testing.md`.
-- Multi-service/distributed boundaries: `microservices.md`, `event-driven.md`, `database-design.md`, `api-docs.md`, `architecture.md`.
+- Data/schema/persistence: `architecture.md`, `database-design.md`, `migrations.md`, `performance.md`, `testing.md`.
+- Endpoint/API/error contracts: `architecture.md`, `api-docs.md`, `api-versioning.md`, `error-handling.md`, `observability.md`, `security.md`, `testing.md`.
+- Auth/secrets/uploads/permissions: `security.md`, `config-and-flags.md`, `error-handling.md`, `observability.md`, `testing.md`.
+- Queue/worker/cron/events/retry: `event-driven.md`, `background-jobs.md`, `resilience.md`, `database-design.md`, `error-handling.md`, `observability.md`, `performance.md`, `testing.md`.
+- Multi-service/distributed boundaries: `microservices.md`, `event-driven.md`, `database-design.md`, `api-docs.md`, `architecture.md`, `resilience.md`, `observability.md`, `performance.md`.
 
 Use the union once when scopes overlap. Do not create framework-specific governance adapters.
 
@@ -67,9 +67,8 @@ Execution Contracts are dynamic execution contracts from prompts, review checkli
 
 ### Layer 5: Prompts
 
-Location: `.agent-context/prompts/`.
-
-Load the matching prompt only:
+Location: `.agent-context/prompts/`. Load the matching prompt only, plus `compact-natural-mode.md` as the default final-response contract:
+- `compact-natural-mode.md` -> final response shape, evidence preservation, and compact natural prose
 - `init-project.md` -> create, build, new project, scaffold
 - `refactor.md` -> refactor, improve, clean up, fix
 - `review-code.md` -> review, audit, check, analyze
@@ -159,7 +158,6 @@ Action: one-line bounded next step
 Use valid rule IDs only; do not quote full rule prose, expose hidden chain-of-thought, or require the block for trivial replies.
 
 ## Definition of Done
-
 Never claim done without:
 1. Relevant rules applied.
 2. PR and architecture checklists considered.
@@ -177,4 +175,4 @@ Verify reachability when relevant: Layer 1 Rules, Layer 2 Runtime Decision Signa
 - Before PR: run review checklists.
 - Before deploy: check policy thresholds.
 - Before major refactor: read `architecture-map.md`.
-- Before UI implementation: confirm valid style context, design contract, and required docs.
+- Before UI implementation: confirm valid style context, design contract, and required docs.