@ryuenn3123/agentic-senior-core 4.3.2 → 4.3.5

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

@@ -2,35 +2,15 @@
 id_prefix: PERF
 domain: performance
 priority: medium
-scope: all-tasks
-applies_to:
-  - backend
-  - frontend
-  - fullstack
-keywords:
-  - performance
-  - perf
-  - caching
-  - bottleneck
-  - runtime
-  - payload
+scope: backend
+applies_to: [backend, frontend, fullstack]
+keywords: [performance, perf, optimization]
 ---
 
 # Performance Boundary
 
-Performance is a decision input, not a blanket veto against modern libraries, motion, richer UI, or maintained tooling.
-
-## PERF-001: Hard Performance Rejections and Caching
-
-1. Do not over-optimize by habit.
-2. Reject obvious scale and runtime failures.
-3. Compare the real cost of the dependency or implementation against the cost of custom code, lost accessibility, weaker UX, duplicated maintenance, and slower delivery.
-4. Reject repeated network, database, filesystem, or model calls inside loops without batching, limits, or caching rationale.
-5. Reject unbounded reads, renders, exports, or searches when the data can grow.
-6. Reject shipping large client/runtime payloads without a reason, split point, or loading strategy.
-7. Reject synchronous blocking work in request, UI, worker, or async paths where it can stall the product.
-8. Reject caches without invalidation, expiry, ownership, and staleness trade-offs.
-9. When performance matters, measure the real bottleneck, change the smallest useful thing, and verify the result.
-10. Do not downshift product quality, UI ambition, or library fit from performance fear alone; name the concrete budget, bottleneck, device limit, or runtime evidence.
-11. Treat caching as a tier decision before a technology decision: prefer browser, CDN, or HTTP cache layers when data is shared and public; prefer in-process caches for hot per-instance data; reach for distributed caches such as Redis or Memcached only when shared mutable state across instances is the actual requirement.
-12. Record cache-aside, write-through, or write-behind shape, invalidation strategy, and stampede prevention such as request coalescing or stale-while-revalidate when the cache fronts an expensive backend.
+## PERF-001: Execution Rules
+1. Optimize DB queries before adding caches.
+2. Compress network payloads.
+3. Bound memory usage (paginate, stream). No unbounded arrays.
+4. Cache aggressively but define explicit cache invalidation.

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

@@ -3,29 +3,14 @@ id_prefix: RT
 domain: realtime
 priority: medium
 scope: backend
-applies_to:
-  - backend
-  - fullstack
-keywords:
-  - realtime
-  - rt
-  - transport
-  - streaming
-  - connection
-  - delivery
+applies_to: [backend, fullstack]
+keywords: [realtime, websockets, sse]
 ---
 
 # Realtime Boundary
 
-Use realtime only when the user experience needs live state, collaboration, streaming progress, notifications, or low-latency feedback. Do not add sockets by habit.
-
-## RT-001: Hard Realtime Transport and Delivery Rules
-
-1. Choose the transport from product needs and current official docs: polling, server-sent events, WebSockets, WebRTC, managed realtime, or queue-backed push.
-2. Authenticate every connection or subscription at a trusted boundary.
-3. Validate every inbound message and keep message contracts typed.
-4. Keep business logic out of transport callbacks.
-5. Define reconnect, heartbeat, backpressure, rate-limit, and abuse behavior.
-6. Plan horizontal scaling before relying on in-memory connection state.
-7. Document ordering, delivery guarantees, offline behavior, and failure recovery.
-8. If realtime infrastructure is unresolved, recommend the smallest current project-fit option instead of assuming WebSockets.
+## RT-001: Execution Rules
+1. Use SSE for one-way server-to-client streams. Use WebSockets only for true bi-directional.
+2. Realtime connections must gracefully degrade to polling if blocked.
+3. Implement ping/pong heartbeats to drop dead connections.
+4. Scale pub/sub via Redis or dedicated brokers.

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

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

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

@@ -3,71 +3,16 @@ id_prefix: SEC
 domain: security
 priority: critical
 scope: all-tasks
-last_validated: 2026-05-17
-applies_to:
-  - backend
-  - frontend
-  - fullstack
-keywords:
-  - security
-  - sec
-  - boundary
-  - hard
-  - rules
-  - zero-trust
+applies_to: [backend, frontend, fullstack]
+keywords: [security, boundary, zero-trust]
 ---
 
 # Security Boundary
 
-Use the security model and libraries already present in the project. If security tooling is unresolved, the LLM must recommend current, maintained options from official docs and OWASP-aligned guidance before implementation.
-
-## SEC-001: Hard rules
-
-1. validate and normalize all data crossing a trust boundary
-2. never interpolate untrusted input into queries, shell commands, file paths, templates, logs, or HTML
-3. never commit secrets, tokens, credentials, private keys, or production identifiers
-4. never invent custom crypto, session, token, or password handling when maintained standards exist
-5. enforce authorization at the server or trusted boundary, not only in UI state
-6. return safe client-facing errors and keep sensitive detail in protected logs
-7. document auth, permission, data exposure, rate-limit, and abuse assumptions before changing sensitive flows
-8. apply least privilege to service accounts, API tokens, database users, background jobs, and operator/admin actions
-9. retrieve secrets through environment, runtime secret injection, or the project's secret manager; do not store static secrets in source or plaintext config
-10. keep `.env` and local secret files covered by `.gitignore`; commit only safe examples such as `.env.example`
-11. treat transport encryption, secure cookies, and trusted proxy boundaries as deployment assumptions that must be documented when sensitive traffic is involved
-12. when a public surface exists, record explicit decisions for: CORS allow-list (not `*` for credentialed requests), security headers (CSP, HSTS, `X-Content-Type-Options`, `Referrer-Policy`, `Permissions-Policy`), JWT pitfalls (algorithm pinning, expiration, refresh rotation, storage location), webhook signature verification with timing-safe compare, SSRF defense (egress allow-list or URL validation) when the server fetches user-supplied URLs, and per-resource authorization (not role-only) when records have owners
-
-## SEC-002: Zero-trust API input rules
-
-1. Treat body, query, params, headers, cookies, uploaded files, webhook payloads, and background job payloads as untrusted until validated.
-2. Validate and normalize input at the outer boundary before it reaches service, use-case, repository, or domain logic.
-3. Services should receive typed, already-validated values and still enforce domain invariants for security-sensitive rules.
-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. -->
+## SEC-001: Execution Rules
+1. Validate and normalize ALL inputs.
+2. Parameterize all SQL queries. Never interpolate input into DB or Shell.
+3. Hash passwords with Argon2/Bcrypt. NEVER store plain text or use MD5/SHA.
+4. NEVER commit secrets, tokens, or credentials.
+5. Implement resource-aware authorization (Row-Level), not just Authentication.
+6. Verify service-to-service cryptographic identity.

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

@@ -1,42 +1,16 @@
 ---
 id_prefix: TEST
 domain: testing
-priority: high
+priority: medium
 scope: all-tasks
-applies_to:
-  - backend
-  - frontend
-  - fullstack
-keywords:
-  - testing
-  - test
-  - behavior
-  - contract
-  - failure
-  - boundaries
+applies_to: [backend, frontend, fullstack]
+keywords: [testing, tests, coverage]
 ---
 
 # Testing Boundary
 
-Use the test runner and style already present in the repo.
-
-## TEST-001: Test Scope
-
-1. If no test setup exists, recommend a current, lightweight, project-fit setup from official docs before adding one.
-2. Test what can break: business rules, validation, authorization, state transitions, and error paths.
-3. Test public APIs, UI flows, integration boundaries, and data contracts touched by the change.
-4. Test regressions around bugs being fixed.
-5. Test critical accessibility or responsive behavior when UI is in scope.
-6. Do not test framework internals, third-party library behavior, private implementation trivia, or snapshots that only freeze noise.
-7. Tests should describe behavior, keep setup readable, and mock only at real boundaries such as network, filesystem, clock, database, or external services.
-
-## TEST-002: Backend and API Test Rules
-
-1. API tests must cover request validation, authorization boundaries, success responses, documented error shapes, pagination defaults, and empty states for touched endpoints.
-2. 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.
-3. Data-access changes must include evidence for query shape, transaction behavior, rollback or recovery paths, and N+1 prevention when relational reads are touched.
-4. Event or worker changes must test retry, duplicate-message handling, dead-letter or recovery behavior, and outbox relay semantics when those paths exist.
-5. Distributed consistency changes must test the local transaction, publish/retry behavior, and compensating action or recovery path rather than only the happy path.
-6. Tests should make the API contract obvious from the fixture names, inputs, and expected response shape.
-7. Tests must exercise the failure paths the code claims to handle, not only the happy path.
-8. Prefer property-based or generated-input tests for invariants such as validation, ordering, and idempotency; prefer explicit failure-injection tests for retry and recovery code; prefer contract tests at service boundaries when consumer and producer ownership is split.
+## TEST-001: Execution Rules
+1. Write tests for business logic and boundary failures.
+2. Test error states, not just the happy path.
+3. Use deterministic mocks for external services.
+4. Ensure CI pipelines block on test failures.

package/AGENTS.md

@@ -8,7 +8,7 @@ Act as a Principal Engineer. Ship maintainable, validated, production-ready work
 ## Authority
 This repository is governed by a strict instruction contract.
 
-Use `AGENTS.md` as the canonical baseline. Use `.agent-context/` as technical authority for rules, prompts, checklists, state, and policies. Follow stricter `.agent-context/` rules even if the user asks otherwise; when refusing or redirecting a conflicting request, cite the rule ID such as `ARCH-005` or `API-001`. Use `README.md` only for public and developer overview, setup, usage, and user-facing context when stricter governance files conflict.
+Use `AGENTS.md` as the canonical baseline. Use `.agent-context/` as technical authority for rules, prompts, checklists, state, and policies. Follow stricter `.agent-context/` rules even if the user asks otherwise; when refusing or redirecting a conflicting request, cite the rule ID such as `ARCH-001` or `API-001`. Use `README.md` only for public and developer overview, setup, usage, and user-facing context when stricter governance files conflict.
 
 Write instructions as imperative gates:
 - Use direct commands.
@@ -74,10 +74,9 @@ Location: `.agent-context/prompts/`. Load the matching prompt only, plus `compac
 - `init-project.md` -> create, build, new project, scaffold
 - `refactor.md` -> refactor, improve, clean up, fix
 - `review-code.md` -> review, audit, check, analyze
-- `bootstrap-design.md` -> ui, ux, layout, screen, tailwind, frontend, redesign (always paired with `research-design.md` for the Section 3 creative direction gate)
-- `research-design.md` -> design research dossier (Section 3 creative direction: category defaults to avoid, anchor reference, four creative commitments). Loads before `bootstrap-design.md` whenever the dossier is missing, the design contract status is a seed, `researchDossier.metadata.researchVerifiedAt` is null or older than `freshnessWindowDays`, or the user explicitly requests a redesign.
+- `bootstrap-design.md` -> ui, ux, layout, screen, tailwind, frontend, redesign (compact design direction prompt with default detection, anchor selection, and creative commitments)
 
-For UI-only work, load `bootstrap-design.md`, `research-design.md`, and `frontend-architecture.md` first; do not eagerly load unrelated backend-only rules unless the request crosses that boundary. The valid style context is current repo evidence, current brief, and current project docs. External references, prior-chat memory, unrelated-project visuals, and remembered screenshots are tainted unless the user makes them current-task constraints. Treat WCAG 2.2 AA as the hard compliance floor and APCA as advisory perceptual tuning only. Do not require screenshot capture as a baseline dependency.
+For UI-only work, load `bootstrap-design.md` and `frontend-architecture.md` first; do not eagerly load unrelated backend-only rules unless the request crosses that boundary. The valid style context is current repo evidence, current brief, and current project docs. External references, prior-chat memory, unrelated-project visuals, and remembered screenshots are tainted unless the user makes them current-task constraints. Treat WCAG 2.2 AA as the hard compliance floor and APCA as advisory perceptual tuning only.
 
 ### Layer 6: Governance Modes
 
@@ -93,7 +92,7 @@ Use `.agent-context/policies/` for quality gates, release thresholds, and audit
 
 ### Layer 9: Project Context
 
-Use root `README.md` as the public and developer entrypoint for every fresh or existing project. Use `docs/doc-index.md` as the compact routing map when `docs/` exists. Use `docs/` when present: `project-brief.md`, `architecture-decision-record.md`, `database-schema.md`, `api-contract.md`, `flow-overview.md`, `DESIGN.md`, `design-intent.json`.
+Use root `README.md` as the public and developer entrypoint for every fresh or existing project. Use `docs/doc-index.md` as the compact routing map when `docs/` exists. Use `docs/` when present: `project-brief.md`, `architecture-decision-record.md`, `database-schema.md`, `api-contract.md`, `flow-overview.md`, `DESIGN.md`.
 
 ## Mandatory Triggers
 
@@ -102,7 +101,7 @@ Use root `README.md` as the public and developer entrypoint for every fresh or e
 Trigger: docs, documentation, dokumen, `docs/*`, architecture docs, flow docs, API docs, or "lengkapkan docs".
 
 1. Load `architecture.md`, `api-docs.md`, and only additional rules required by scope.
-2. Create or refine required docs first: root `README.md` for every fresh or existing project; `docs/doc-index.md` whenever `docs/` exists; `docs/project-brief.md`; `docs/architecture-decision-record.md`; `docs/flow-overview.md`; `docs/api-contract.md` for APIs, firmware endpoints, CLI commands, or web application flows; `docs/database-schema.md` for persistent data; and `docs/DESIGN.md` plus `docs/design-intent.json` for UI scope.
+2. Create or refine required docs first: root `README.md` for every fresh or existing project; `docs/doc-index.md` whenever `docs/` exists; `docs/project-brief.md`; `docs/architecture-decision-record.md`; `docs/flow-overview.md`; `docs/api-contract.md` for APIs, firmware endpoints, CLI commands, or web application flows; `docs/database-schema.md` for persistent data; and `docs/DESIGN.md` for UI scope.
 3. Use Mermaid.js as the default diagram format for all documentation diagrams (flowcharts, sequence, ER, C4, state). Embed as fenced `mermaid` code blocks. Do not use PlantUML, ASCII art diagrams, Graphviz DOT, or Structurizr DSL. When updating existing docs that contain prose-only descriptions, convert relevant sections to Mermaid diagrams in the same change.
 4. Use `docs/doc-index.md` as the compact read-routing map; add PRD, SRS, technical-design, or separate ERD only when justified. Write formal project docs in English by default.
 5. Stop after documentation when the user only asked for docs. Do not write application, firmware, or UI code until the user asks or approves implementation; do not write application, firmware, or UI code before approval.
@@ -137,23 +136,17 @@ Load `pr-checklist.md` and `architecture-review.md`, then report defects, risks,
 
 Trigger: ui, ux, layout, screen, tailwind, frontend, redesign.
 
-1. Read `bootstrap-design.md`, `research-design.md`, and `frontend-architecture.md`. Read UI-relevant repo evidence from state, current UI code, and `docs/*`.
-2. Detect user-explicit redesign first ("redesign from zero", "redesain dari 0", "ulang dari 0", "research ulang", any explicit reset). It bypasses the freshness gate; run research-design.md regardless of dossier age and treat existing direction as anti-repeat ledger input only.
-3. Route by `docs/design-intent.json` state. File missing, status one of `seed-needs-design-synthesis`, `seed-generated-during-init`, `seed-generated-during-upgrade`, OR active with `researchDossier.metadata.researchVerifiedAt` null or older than `freshnessWindowDays` (90): run research-design.md, then bootstrap-design.md, then flip status to active and write today's ISO date to `researchVerifiedAt`. Active and fresh and no explicit redesign: run bootstrap-design.md only for additive UI tasks; do not auto-refresh `researchVerifiedAt`.
-4. Scenario routing: backend-only init then later UI request (Scenario B) requires `npx @ryuenn3123/agentic-senior-core upgrade` to re-sync UI governance when `bootstrap-design.md` or `research-design.md` is missing; upgrade-migrated metadata (Scenario D) and init on existing project that already had design-intent.json (Scenario E) populate the anti-repeat ledger from previous anchor, palette, and motion. Treat every ledger entry as a hard blocklist when running research-design.md.
-5. Anti-repeat ledger contract: read `researchDossier.metadata.antiRepeatLedger` before producing candidates. The chosen anchor must differ from every blocklisted entry on at least conceptual family, hierarchy implication, and motion implication. Restating an existing direction with new wording is REVISE.
-6. Include a one-line Motion/Palette Decision before UI code; product categories are heuristics, not style presets. Record one real-world anchor, one signature motion behavior, and one typographic role contrast.
-7. Ensure `docs/design-intent.json` includes `conceptualAnchor.anchorReference`, top-level `derivedTokenLogic`, `researchDossier.metadata`, `libraryResearchStatus`, `libraryDecisions[]`, and motion/palette decisions. Generate or refine `docs/DESIGN.md` plus `docs/design-intent.json` before UI implementation.
-8. Keep context isolated; do not eagerly load unrelated backend-only rules. For broad screens or redesigns, treat expressive motion, spatial hierarchy, distinctive composition, and product-specific interaction as the baseline; quiet or static surfaces require a concrete product, performance, accessibility, device, or dependency reason.
-9. Do not let conceptual anchors collapse into room, darkroom, counting room, control room, war room, studio, lab, cockpit, or command center by habit. Prefer artifacts, workflows, custody chains, instruments, data behaviors, material systems, editorial systems, service rituals, or interaction mechanisms unless a physical place model is core to the product.
-10. External websites and benchmark examples are candidate evidence for constraints, mechanics, and quality bars only. Do not copy their layout rhythm, palette, component skin, visual metaphor, or brand posture without explicit user approval and product-fit rationale.
+1. Read `bootstrap-design.md` and `frontend-architecture.md`. Read UI-relevant repo evidence from state, current UI code, and `docs/*`.
+2. Follow the three-step direction process in `bootstrap-design.md`: name defaults, choose anchor, commit to creative direction. If `docs/DESIGN.md` has an anti-repeat ledger, load previous directions as blocklist.
+3. Generate or refine `docs/DESIGN.md` before UI implementation. Keep context isolated; do not eagerly load unrelated backend-only rules.
+4. External websites are evidence for constraints and mechanics only. Do not copy layout rhythm, palette, component skin, or brand posture without explicit user approval.
 
 ## Bounded Reflection
 For risky actions (file edits, public contracts, rule conflicts/refusals, release/publish gates, or security/data/API/testing/architecture boundaries), show this compact block before action or refusal:
 
 ```text
 REFLECTION
-Rules: ARCH-003, TEST-001
+Rules: ARCH-001, TEST-001
 Risk: one-line risk or conflict
 Action: one-line bounded next step
 ```
@@ -163,7 +156,7 @@ Use valid rule IDs only; do not quote full rule prose, expose hidden chain-of-th
 Never claim done without:
 1. Relevant rules applied.
 2. PR and architecture checklists considered.
-3. Universal SOP gates satisfied: public and developer root `README.md`; `docs/doc-index.md` when `docs/` exists; `docs/project-brief.md`; `docs/architecture-decision-record.md`; `docs/flow-overview.md`; `docs/database-schema.md` when persistent data exists; `docs/api-contract.md` when API or web application flows exist; plus `docs/DESIGN.md` and `docs/design-intent.json` for UI scope.
+3. Universal SOP gates satisfied: public and developer root `README.md`; `docs/doc-index.md` when `docs/` exists; `docs/project-brief.md`; `docs/architecture-decision-record.md`; `docs/flow-overview.md`; `docs/database-schema.md` when persistent data exists; `docs/api-contract.md` when API or web application flows exist; plus `docs/DESIGN.md` for UI scope.
 4. If `.agent-context/state/active-memory.json` exists and material project progress happened, refresh it while preserving privacy rules and user-owned entries.
 5. Project validation passed through `npm run validate`.
 

package/README.md

@@ -135,7 +135,7 @@ Adds six backend rule files (`OBS-*`, `RES-*`, `MIG-*`, `JOB-*`, `CFG-*`, `VER-*
 
 Numbered Markdown rules with stable section IDs, bounded reflection, provider-free anti-halu benchmark, three-layer prompt caching contract, and per-integration caching scope enforcement. Caching numbers are scoped per integration; IDE wrapper integrations receive prefix stability without a measurable per-pack saving. See [docs/benchmark-reference.md](docs/benchmark-reference.md) for the reporting format and [CHANGELOG.md](CHANGELOG.md) for details.
 
-Current package version: 4.2.0. Last published version: 4.0.3.
+Current package version: 4.3.3. Last published version: 4.3.2.
 
 ---
 

package/lib/cli/adaptive-context/catalog.mjs

@@ -404,15 +404,10 @@ export const PROMPT_CATALOG = [
     promptPath: '.agent-context/prompts/init-project.md',
     triggers: ['create', 'build', 'new project', 'scaffold', 'fresh project', 'bikin project'],
   },
-  {
-    promptPath: '.agent-context/prompts/research-design.md',
-    labels: ['FE'],
-    triggers: ['redesign', 'redesain', 'ulang dari 0', 'research ulang'],
-  },
   {
     promptPath: '.agent-context/prompts/bootstrap-design.md',
     labels: ['FE'],
-    triggers: ['ui', 'ux', 'frontend', 'layout', 'screen', 'redesign', 'redesain'],
+    triggers: ['ui', 'ux', 'frontend', 'layout', 'screen', 'redesign', 'redesain', 'ulang dari 0', 'research ulang'],
   },
 ];