@ryuenn3123/agentic-senior-core 3.0.44 → 3.0.46

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

@@ -5,15 +5,13 @@ Use this prompt for UI, UX, frontend layout, screen, Tailwind, animation, 3D, ca
 Create or refine `docs/DESIGN.md` for human reasoning and `docs/design-intent.json` for machine-readable design intent, guardrails, and review signals.
 
 This contract is a decision scaffold, not a style preset. We guide the agent; we do not pick the final style, stack, framework, palette, typography, layout paradigm, or animation library offline.
-
 ## Authority
 - Treat `.agent-context/` and current project docs as technical authority.
-- Treat `README.md` as overview, install, and user-facing context only. Do not use it as coding, architecture, or design authority when `.agent-context/` gives a stricter rule.
+- Treat `README.md` as public and developer overview, setup, usage, and user-facing context only. Do not use it as coding, architecture, or design authority when `.agent-context/` gives a stricter rule.
 - Use current repo evidence, product copy, route names, component names, user goals, and existing constraints as the source of truth.
 - Treat prior-chat visuals, unrelated project memory, benchmark screenshots, and famous-product aesthetics as tainted context unless the user explicitly approves continuity.
 - Keep external references non-copying; extract constraints only.
 - Before choosing a new UI, animation, scroll, 3D, canvas, chart, icon, styling, or component library, research current official docs.
-
 ## Required Order
 1. Read `AGENTS.md`, this prompt, `../rules/frontend-architecture.md`, current UI code, current project docs, and existing design docs.
 2. Refine existing `docs/DESIGN.md` and `docs/design-intent.json`; do not replace them blindly.
@@ -21,7 +19,6 @@ This contract is a decision scaffold, not a style preset. We guide the agent; we
 4. Record `motionPaletteDecision` before UI code; product categories are heuristics, not style presets.
 5. Encode `repoEvidence.designEvidenceSummary` when onboarding or detector evidence exists.
 6. Keep both design docs synchronized after implementation.
-
 ## Creative Commitment Gate
 Before broad compliance review or UI implementation, record an agent-chosen visual direction in both design docs:
 - one concrete real-world anchor reference
@@ -30,7 +27,6 @@ Before broad compliance review or UI implementation, record an agent-chosen visu
 - one authored visual bet visible in the first viewport
 
 Reject generic anchors. Do not accept "modern", "clean", "premium", "expressive", "minimal", or "bold" as the anchor. Name a material, instrument, artifact class, architectural system, editorial genre, cinematic behavior, exhibition system, scientific apparatus, or industrial mechanism.
-
 ## Dynamic Avant-Garde Anchor Engine
 If no current-task research or visual reference exists, activate the Dynamic Avant-Garde Anchor Engine before coding.
 
@@ -40,10 +36,11 @@ Rules:
 - Discard the two safest or most predictable options.
 - Output only the chosen anchor, specific reference point, and rationale.
 - Forbid final anchors named dashboard, portal, cards, admin panel, SaaS shell, web app shell, or minimalist interface.
+- Do not default to spatial place metaphors such as room, darkroom, control room, counting room, war room, studio, lab, cockpit, or command center. Use them only when the product truly depends on a physical place model.
+- Prefer artifacts, custody flows, instruments, data behaviors, materials, editorial systems, service rituals, or interaction mechanisms over "where the interface lives" as the anchor.
 - Derive typography, spacing, density, color behavior, morphology, motion, and responsive composition from the chosen anchor.
 - Translate the anchor non-literally first. Anchor artifacts are evidence for behavior, hierarchy, density, typography, state language, and motion, not automatic UI chrome.
 - Use reduced-motion fallbacks instead of suppressing motion.
-
 ## Creative Ambition Floor
 Before UI code, record:
 - one product-derived palette move
@@ -52,19 +49,18 @@ Before UI code, record:
 - at least three at-a-glance product-specific signals for new screens or broad redesigns
 
 Do not ship AI-safe UI. Record exact drift signals in `reviewRubric`; at minimum reject decorative grid wallpaper, default line backgrounds, calibration-mark wallpaper, soft glow backgrounds, generic abstract marks, testing/demo/placeholder UI copy, terminal-only user flows, and first-output composition with only local copy swapped in when they have no product function. Treat measurement, calibration, crop, route, timeline, and inspection marks as task overlays or control affordances only; never promote them to the page background, hero backdrop, or first-output visual texture. If a conceptual anchor suggests a forbidden motif, the forbidden motif wins; express the anchor through workflow, hierarchy, density, typography, material behavior, state design, and interaction grammar instead of literal wallpaper.
-
 ## Brave Redesign Default
 For UI design work, the agent owns the ambition decision. For broad screens, redesigns, or new visual systems, treat expressive motion, spatial hierarchy, distinctive composition, and product-specific interaction as the baseline even when the user did not say "rich". Do not reduce the request to a safer version of the existing UI, a static implementation, or a component-kit rearrangement because research or dependency selection feels inconvenient.
 
 If the expressive path needs a new motion, 3D, canvas, scroll, or interaction library and web search is available, perform the official-doc research and record the decision. If web search is unavailable, use already-present dependencies or native browser capabilities while preserving the intended ambition, then mark library verification as pending.
 
 Only downshift ambition after naming the concrete blocker: product fit, content density, measured performance budget, accessibility, device support, package conflict, security risk, or missing runtime capability. A new dependency, package count, or vague performance concern is not a blocker by itself. Pair every downshift with a replacement interaction quality that still changes composition, hierarchy, feedback, or memorability.
-
 ## Design Flexibility Layer
-
 `docs/design-intent.json` must separate locked outcomes from flexible expression. The machine contract keeps review invariants stable; it must not freeze exact aesthetic implementation unless repo evidence, accessibility validation, implementation constraints, or explicit user approval locks it.
 
-Record `designFlexibilityPolicy`: lock user goals, runtime constraints, accessibility, production readiness, forbidden patterns, and approved continuity; keep exact palette primitives, font families, radius/shadow values, component-kit theme mapping, signature move implementation, and literal anchor artifacts flexible until validated or approved. Semantic roles are required; exact primitives are not automatically locked. Required experience outcomes are separate from candidate implementation moves. Libraries supply behavior, accessibility, primitives, and delivery speed; the project supplies final composition, theme, morphology, and visual language.
+Record `designFlexibilityPolicy`: lock user goals, runtime constraints, accessibility, production readiness, forbidden patterns, and approved continuity; keep exact palette primitives, font families, radius/shadow values, component-kit theme mapping, signature move implementation, literal anchor artifacts, and spatial metaphors flexible until validated or approved. Semantic roles are required; exact primitives are not automatically locked. Required experience outcomes are separate from candidate implementation moves. Libraries supply behavior, accessibility, primitives, and delivery speed; the project supplies final composition, theme, morphology, and visual language.
+## External Inspiration Boundary
+Using outside websites, benchmark apps, galleries, or component examples is useful for constraint discovery, interaction mechanics, and implementation options, but never as a style source to imitate. Extract why a pattern works, then translate it into a current-project rule. Do not copy layout rhythm, palette, component skin, visual metaphor, or brand posture from a reference unless the user explicitly approves that continuity and it passes product fit.
 
 ## AI Color and Template Residue Audit
 AI color drift happens when a palette uses safe defaults before product meaning.
@@ -108,8 +104,12 @@ If web search is unavailable:
 - Use native CSS, browser APIs, or already-present dependencies.
 - Set `libraryResearchStatus` to `pending-verification`.
 
-Treat unresearched dependency choices as review findings. Dynamic UI Foundation Selection: do not default to shadcn/ui, Tailwind-only, native-only, or any component kit because it is familiar. Choose the foundation from product type, interaction complexity, accessibility needs, design ambition, team/runtime constraints, bundle/runtime cost, and current official docs.
+Treat unresearched dependency choices as review findings. Dynamic UI Foundation Selection: do not default to shadcn/ui, Tailwind-only, native-only, or any component kit because it is familiar, and do not avoid them because a guardrail exists. Choose the foundation from product type, interaction complexity, accessibility needs, design ambition, team/runtime constraints, bundle/runtime cost, and current official docs.
 Ready-made primitives are allowed when they improve behavior, accessibility, speed, or maintainability. The library supplies mechanics; the project supplies visual language. Reject default component-kit styling without product rationale, but do not reject a modern lightweight library solely because a dependency was needed.
+
+Tailwind-first is valid only as an implementation fit, not as ideology or anti-ideology. Use Tailwind utilities and CSS-first tokens when they fit the chosen stack and team, but do not make pure Tailwind, vanilla CSS, shadcn/ui, or any component kit the default answer when product evidence points to stronger primitives, charts, motion, gestures, canvas, or framework tooling.
+
+For fresh projects, prefer official framework scaffolders or setup commands when current official docs show they create the supported project shape. Manual from-scratch file assembly is acceptable for tiny prototypes, educational exercises, repo-specific constraints, or when official scaffolders cannot satisfy the approved architecture; document that reason.
 ## Zero-Based Redesign Protocol
 
 When the user says "redesign from zero", "redesain dari 0", "ulang dari 0", or "research ulang":

package/.agent-context/prompts/init-project.md

@@ -10,12 +10,13 @@ When a new project is created or initialized, the agent must automatically:
 3. Review dynamic runtime signals from [.agent-context/state/onboarding-report.json](../state/onboarding-report.json), repository evidence, task constraints, and live official documentation when runtime or ecosystem facts matter.
 4. If Docker or Compose is in scope, load [docker-runtime.md](../rules/docker-runtime.md) and verify the latest official Docker guidance before authoring container assets. Materialize the selected development/production assets rather than stopping at prose.
 5. For unresolved framework or package setup, recommend the latest stable compatible dependency set and official framework setup flow from live official documentation before coding unless a documented compatibility constraint blocks it.
+6. Do not default fresh web projects to Next.js, Tailwind-only styling, shadcn/ui, Vite, or any framework by habit, and do not avoid them because of this guard when they are the strongest fit. Treat explicit user constraints as constraints; otherwise compare project needs, runtime boundaries, hosting, data flow, team workflow, and official setup guidance before recommending.
 
 ## Required Planning Mode
 
 If the user describes a project or feature, the agent must:
 1. Clarify the delivery goals, runtime assumptions, constraints, and must-have capabilities before choosing implementation shape.
-2. If the user already named a stack or framework, treat it as an explicit constraint. If not, produce a short evidence-backed recommendation from the brief, repo evidence, and live official documentation before coding.
+2. If the user already named a stack or framework, treat it as an explicit constraint. If not, produce a short evidence-backed recommendation from the brief, repo evidence, and live official documentation before coding. Include at least one plausible alternative when the default-looking option is Next.js, Tailwind-only styling, shadcn/ui, or another familiar web stack.
 3. For existing projects, inspect real files first. Do not derive product name, description, runtime, architecture, or design direction from the folder name alone.
 4. Draft a high-level structure plan plus the docs/bootstrap artifacts that must exist before coding.
 5. Wait for user approval before scaffolding the project.
@@ -25,9 +26,12 @@ If the user describes a project or feature, the agent must:
 If the user asks to create, complete, fix, or review project docs, documentation, dokumen, `docs/*`, architecture docs, flow docs, API docs, or "lengkapkan docs", treat the request as documentation-first.
 
 The agent must:
-1. Materialize or refine required project docs before implementation: `docs/project-brief.md`, `docs/architecture-decision-record.md`, `docs/flow-overview.md`, `docs/api-contract.md` when APIs, firmware endpoints, CLI commands, or web application flows exist, `docs/database-schema.md` when persistent data exists, and `docs/DESIGN.md` plus `docs/design-intent.json` for UI scope.
+1. Materialize or refine required project docs before implementation: root `README.md` for every fresh or existing project; `docs/project-brief.md`; `docs/architecture-decision-record.md`; `docs/flow-overview.md`; `docs/api-contract.md` when APIs, firmware endpoints, CLI commands, or web application flows exist; `docs/database-schema.md` when persistent data exists; and `docs/DESIGN.md` plus `docs/design-intent.json` for UI scope.
 2. Write formal project docs in English by default unless the user explicitly asks for another documentation language.
-3. Stop after docs when the user only asked for docs. Do not write application, firmware, or UI code until the user explicitly asks for implementation or approves the implementation plan.
+3. Keep `README.md` public and developer friendly even for private projects: explain what the project is, who it is for, how to set it up, how to run the core workflow, how to configure it, and where deeper docs live. Do not put internal agent notes, private reasoning, secrets, or governance policy in the README.
+4. Keep documentation alive. When project behavior, setup, architecture, public contracts, data shape, deployment, or UI scope changes, update the matching docs in the same change.
+5. Avoid documentation sprawl. Add a new docs file only when the topic is stable, long enough to outgrow the README or core docs, or owned by a separate workflow such as hardware setup, deployment, troubleshooting, or testing validation.
+6. Stop after docs when the user only asked for docs. Do not write application, firmware, or UI code until the user explicitly asks for implementation or approves the implementation plan.
 
 ## Direct Constraint Mode
 
@@ -42,6 +46,7 @@ If the user specifies a framework, runtime, or architecture constraint, the agen
    - Every module must follow [architecture.md](../rules/architecture.md).
    - Every dependency must be justified per [efficiency-vs-hype.md](../rules/efficiency-vs-hype.md).
    - Use official framework setup commands or canonical starter flows when they produce newer, better-supported dependency defaults than manual package assembly.
+   - Do not assemble a framework project from scratch by habit when official setup commands create the supported structure. Manual assembly is allowed only for tiny prototypes, educational demos, unusual repo constraints, or a documented architecture reason.
    - If containerization is selected, Docker assets must follow [docker-runtime.md](../rules/docker-runtime.md) and the latest official Docker docs instead of stale blog-era patterns. Selected Docker lanes require files and runbooks, not docs-only acknowledgment.
 
 ## Runtime and Architecture Reference

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

@@ -11,7 +11,7 @@ Before editing:
 3. If required project docs are missing, stop and bootstrap or update docs first.
 4. If the change touches UI, load .agent-context/prompts/bootstrap-design.md and .agent-context/rules/frontend-architecture.md 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.
+6. Enforce Universal SOP hard gate: stop implementation if root `README.md` is missing, if `docs/architecture-decision-record.md` is missing, or for UI scope 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.

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

@@ -11,7 +11,7 @@ Before reviewing:
 3. Read .agent-context/review-checklists/architecture-review.md only when architecture or boundaries changed.
 4. Load only the rules relevant to the changed scope.
 5. For UI changes, load .agent-context/prompts/bootstrap-design.md, .agent-context/rules/frontend-architecture.md, 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`).
+6. Enforce Universal SOP hard gate: block coding flow when required project docs are missing (root `README.md`; `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, 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:

package/.agent-context/review-checklists/pr-checklist.md

@@ -60,7 +60,7 @@ Run this before declaring a task done. Apply only the sections relevant to the c
 
 - [ ] Scope applied: This applies to documentation, release notes, onboarding text, review summaries, and agent-facing explanations
 - [ ] Style scope review is advisory and does not block merge when API docs are synced in the same commit and contract details are correct
-- [ ] Required docs exist before implementation: project brief, architecture decision, flow overview, API/public contract when relevant, data model when relevant, and UI design contract when relevant.
+- [ ] Required docs exist before implementation: public and developer root README; project brief; architecture decision; flow overview; API/public contract when relevant; data model when relevant; and UI design contract when relevant.
 - [ ] For docs-only or docs-first requests, implementation code was not changed unless the user explicitly asked for it or approved an implementation plan.
 - [ ] Formal project docs use English by default unless the user requested another language or existing docs established one.
 - [ ] Docs cover feature plan, architecture rationale, public contracts, data model, UI/design, security assumptions, testing strategy, delivery flow, and next validation actions where relevant.
@@ -70,6 +70,9 @@ Run this before declaring a task done. Apply only the sections relevant to the c
 - [ ] Facts, assumptions, and next actions are separated when context is incomplete.
 - [ ] No emoji in formal documentation or review summaries
 - [ ] Documentation uses plain English and avoids AI cliches
+- [ ] Root README is public and developer friendly, even for private projects, and does not contain secrets, internal agent notes, private reasoning, or governance policy dumps.
+- [ ] Documentation grows with the project: README and matching docs were updated when setup, runtime, architecture, public contracts, data shape, deployment, validation, or UI scope changed.
+- [ ] Documentation file count stayed intentional: new docs files were added only for stable, distinct, or long workflows.
 
 ## 7. UI And Accessibility
 
@@ -116,6 +119,7 @@ Run this before declaring a task done. Apply only the sections relevant to the c
 - [ ] `.agent-context/rules/` remains the default guidance source for implementation and review.
 - [ ] Security and testing requirements remain mandatory after static template purge.
 - [ ] Coding flow is blocked if `docs/architecture-decision-record.md` (or `docs/Architecture-Decision-Record.md`) is missing
+- [ ] Coding flow is blocked if root `README.md` is missing
 - [ ] UI implementation flow is blocked if `docs/DESIGN.md` or `docs/design-intent.json` is missing
 
 ## Verdict

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

@@ -4,6 +4,22 @@
 
 If a change affects an API, CLI command, exported library behavior, schema, event, or integration contract, update the matching docs in the same change.
 
+## Public README Boundary
+
+Root `README.md` is required for every fresh or existing project. This includes private projects, because a future maintainer still needs a clear public and developer entrypoint.
+
+README content must be safe for outside readers and useful for developers. It must explain what the project is, who it is for, how to set it up, how to run the main workflow, how to configure it, and where deeper docs live when those topics apply.
+
+Keep README overview-level. Do not make it the canonical governance source. Do not put secrets, private agent notes, hidden reasoning, backlog chatter, raw architecture debate, or internal policy dumps in it.
+
+Choose README sections from project evidence. Do not force a fixed template when a section does not apply. For private/internal projects, keep the same clear style but omit private URLs, credentials, customer names, and internal-only operational details that do not belong in repo docs.
+
+## Documentation Growth Model
+
+Documentation must evolve with the project. When behavior, setup, architecture, public contracts, data shape, deployment, or validation changes, update README and the matching docs in the same change.
+
+Start compact, then split only when a topic earns its own file. Good split signals are: the section is long, the workflow is owned separately, the content is referenced often, or the topic needs step-by-step care such as hardware setup, deployment, testing validation, operations, or troubleshooting.
+
 ## Contract Rules
 
 - Document the public surface before or alongside implementation.

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

@@ -32,17 +32,20 @@ The `.agent-context/rules/` directory is the default guidance source for impleme
 - Backend and frontend mindset checks are both required when a task spans API and UI boundaries.
 - Security and testing are non-negotiable baseline requirements.
 - Hard block before coding:
+  - Root `README.md` must exist for every fresh or existing project and read as a public and developer entrypoint, not an internal agent note.
   - `docs/project-brief.md` must exist.
   - `docs/architecture-decision-record.md` (alias: `docs/Architecture-Decision-Record.md`) must exist.
   - `docs/flow-overview.md` must exist.
   - If the project uses persistent data, `docs/database-schema.md` must exist.
   - If the project exposes API or web application flows, `docs/api-contract.md` must exist.
   - For UI scope, `docs/DESIGN.md` and `docs/design-intent.json` must exist.
-- Required docs coverage must include feature plan, architecture rationale, public contracts, data model when relevant, UI/design when relevant, security assumptions, testing strategy, delivery flow, and next validation actions.
+- Required docs coverage must include a public and developer README entrypoint, feature plan, architecture rationale, public contracts, data model when relevant, UI/design when relevant, security assumptions, testing strategy, delivery flow, and next validation actions.
 - If required project context docs are missing, stop implementation and bootstrap docs before writing application code.
 - Bootstrap flow: analyze the real repo plus the latest user prompt before authoring those docs.
 - Bootstrap docs must be adaptive and project-specific. Do not create generic placeholder templates.
 - When context is incomplete, separate confirmed facts from assumptions, add an `Assumptions to Validate` section, and end with the next validation action.
+- Keep docs current with project changes. Update README and the matching docs whenever setup, runtime, architecture, public contracts, data shape, UI scope, deployment, or validation flow changes.
+- Control docs file count. Keep the baseline compact, then add topic files only when a subject is stable, too long for README/core docs, or belongs to a distinct workflow such as hardware setup, deployment, testing validation, operations, or troubleshooting.
 
 ## Rules as Guardian (Cross-Session Consistency)
 

package/.agent-context/rules/efficiency-vs-hype.md

@@ -12,6 +12,7 @@ Before adding or recommending a dependency:
 - check current official docs, release notes, and setup guidance when the ecosystem decision matters
 - choose the latest stable compatible dependency version unless a project constraint blocks it
 - use the official scaffolder or setup command when it creates the current supported project shape
+- do not hand-assemble fresh framework projects by habit when the official setup flow gives safer current defaults; document the reason when manual assembly is better
 - Only step down to an older dependency version after documenting the exact compatibility, runtime, platform, or ecosystem reason.
 - explain why the dependency is a better tradeoff than local implementation for the current task
 - avoid packages that are stale, thinly maintained, too heavy for the job, or added only because they are popular
@@ -19,3 +20,5 @@ Before adding or recommending a dependency:
 - do not reject a dependency only because it adds a package; reject it only when the project-fit, security, maintenance, compatibility, bundle/runtime, or ownership tradeoff is worse than the alternative
 
 Reject offline dependency decisions, outdated tutorial versions, trend choices, dependency avoidance choices, and performance-fear choices that are not grounded in the current repo, brief, and delivery tradeoffs.
+
+Reject framework autopilot, not frameworks. Next.js, Vite, Astro, React Router, SvelteKit, Laravel, plain HTML, and other runtimes are candidates, not defaults or forbidden choices. If the user did not constrain the stack, compare at least the strongest fit and one plausible alternative before implementation, then choose the technology that removes bottlenecks for this project.

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

@@ -10,10 +10,11 @@ Use this rule for UI, UX, page, screen, component, layout, landing, dashboard, f
 
 - Use current repo evidence, the active brief, and current project docs as valid style context.
 - Treat `.agent-context/` as design governance authority.
-- Treat `README.md` as overview/install/user context only when design or architecture rules conflict.
+- Treat `README.md` as public and developer overview, setup, usage, and user-facing context only when design or architecture rules conflict.
 - Do not choose final style, framework, palette, typography, layout paradigm, or animation library offline.
 - Research current official docs before adding a new UI, animation, scroll, 3D, canvas, charting, icon, styling, or primitive library.
-- Dynamic UI Foundation: do not hardcode shadcn/ui, Tailwind-only, native-only, or any component library as the universal answer. Modern lightweight primitives, motion libraries, canvas/WebGL helpers, charting libraries, and styling tools are valid when product evidence, accessibility, interaction quality, maintainability, delivery speed, runtime constraints, and official docs support them.
+- Dynamic UI Foundation: do not hardcode shadcn/ui, Tailwind-only, native-only, or any component library as the universal answer, and do not avoid them out of guardrail fear when they fit. Tailwind-first is valid when the stack, token model, and team workflow support it; pure Tailwind, vanilla CSS, shadcn/ui, or any kit is not neutral by itself. Modern primitives, motion/canvas/WebGL helpers, charting libraries, and styling tools are valid when product evidence, accessibility, runtime constraints, and official docs support them.
+- For fresh projects, prefer official framework scaffolders or setup commands when official docs show they produce the current supported shape. Build files manually only when approved architecture, repo constraints, or learning/prototype scope makes that better.
 - Keep design continuity opt-in. Repo evidence outranks memory residue.
 
 ## Required Design Contract
@@ -54,6 +55,7 @@ If the user gives no current-task visual research or reference:
 - Do not count old UI, existing design docs, or scaffold seeds as research.
 - Choose one high-variance non-software conceptual anchor before UI code.
 - Internally reject the safest dashboard, portal, card-grid, admin-shell, or minimalist-web-app mental model.
+- Do not let the fallback anchor become a generic place metaphor. Avoid room, darkroom, counting room, control room, war room, studio, lab, cockpit, and command center unless the product actually depends on that place model; prefer product-specific artifacts, workflows, custody chains, instruments, data behaviors, material systems, editorial systems, service rituals, or interaction mechanisms over "where the UI lives".
 - Record one real-world anchor reference, one signature motion behavior, and one typographic decision with role contrast.
 - Derive typography, spacing, morphology, motion, and responsive recomposition from that anchor.
 - Translate the anchor into workflow, hierarchy, density, typography, state behavior, and interaction before using literal artifacts. Do not turn anchor artifacts into required chrome, wallpaper, decorative props, or component-kit theme objects without a named product function.
@@ -71,7 +73,7 @@ If the user gives no current-task visual research or reference:
 - For new screens or broad redesigns, research the expressive implementation path instead of defaulting to static native CSS. Use native or already-installed tools only when they can still deliver the chosen ambition, or when a concrete blocker is documented. Do not downshift because adding a package feels inconvenient; downshift only for a concrete product-fit, accessibility, security, compatibility, device, maintenance, or measured performance reason.
 - Keep reduced-motion, keyboard, loading, performance, mobile, and non-3D fallbacks explicit.
 - Use component kits or headless primitives for behavior and accessibility when they fit. Replace library-default visual language with project-specific composition, tokens, motion, state treatment, and morphology.
-- Keep design-intent flexible: lock user goals, accessibility, production readiness, forbidden patterns, and approved continuity; keep exact palette primitives, font families, radius/shadow values, component skins, and candidate signature moves flexible until evidence or approval locks them.
+- Keep design-intent flexible: lock user goals, accessibility, production readiness, forbidden patterns, and approved continuity; keep exact palette primitives, font families, radius/shadow values, component skins, candidate signature moves, and external website inspiration flexible until evidence or approval locks them. Convert references into product-fit rules; do not copy layout, palette, component skin, brand posture, or visual metaphor.
 ## Zero-Based Redesign
 
 If the user asks for a redesign from zero:

package/.agent-context/state/architecture-map.md

@@ -34,7 +34,7 @@ Use this file as repo-local agent context. It records the current governance arc
 ## Agent Behavior
 
 1. Load the smallest relevant rule set.
-2. Use README only for overview/install/user context when governance files conflict.
+2. Use README only for public and developer overview, setup, usage, and user-facing context when governance files conflict.
 3. Preserve generated adapter sync before release.
 4. Treat stale generated state, dual lockfiles, and obsolete V2/V3 transition files as cleanup findings.
 5. Before claiming done, run the relevant validation gate and report any skipped checks.

package/.cursor/rules/agentic-senior-core.mdc

@@ -7,12 +7,12 @@ alwaysApply: true
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 8a232b1dc9792849a9290898ef40dfff730c13cd0b443d217c0590ced04ed946
+Canonical Snapshot SHA256: c66b5dfe48a25f0df297a1681aa6bab572da95d2201f09abf3767d38a2934591
 
 This repository is governed by a strict instruction contract.
 Use [.instructions.md](../../.instructions.md) as the canonical policy source.
 Use .agent-context/ for technical rules, prompts, checklists, policies, and state.
-Treat README.md as overview/install/user context only when governance files conflict.
+Treat README.md as public and developer overview, setup, usage, and user-facing context only when governance files conflict.
 
 ## Critical Bootstrap Floor
 
@@ -23,6 +23,7 @@ Treat README.md as overview/install/user context only when governance files conf
 - For UI scope, include a one-line Motion/Palette Decision in the Bootstrap Receipt; product categories are heuristics, not style presets.
 - For UI scope, create or refine `docs/DESIGN.md` and `docs/design-intent.json` before UI implementation.
 - For documentation-first requests, create or refine required project docs in English by default and do not write application, firmware, or UI code until the user asks or approves.
+- Create or refine root README.md as the public and developer entrypoint before implementation.
 - For backend, API, data, auth, error, event, queue, worker, or distributed-system requests, load only relevant global rules from .agent-context/rules/ ([link](../../.agent-context/rules)).
 - For ecosystem, framework, dependency, or Docker claims, perform live web research.
 - Resolve runtime choices from project evidence and live official documentation; resolve structural planning from constraints and architecture boundaries.

package/.cursorrules

@@ -1,6 +1,6 @@
 # .cursorrules - Legacy Thin Adapter
 
-Generated by Agentic-Senior-Core CLI v3.0.44
+Generated by Agentic-Senior-Core CLI v3.0.46
 Adapter Mode: legacy-thin
 Adapter Source: .agent-instructions.md when present; fallback .instructions.md
 Canonical baseline: .instructions.md

package/.gemini/instructions.md

@@ -2,12 +2,12 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 8a232b1dc9792849a9290898ef40dfff730c13cd0b443d217c0590ced04ed946
+Canonical Snapshot SHA256: c66b5dfe48a25f0df297a1681aa6bab572da95d2201f09abf3767d38a2934591
 
 This repository is governed by a strict instruction contract.
 Use [.instructions.md](../.instructions.md) as the canonical policy source.
 Use .agent-context/ for technical rules, prompts, checklists, policies, and state.
-Treat README.md as overview/install/user context only when governance files conflict.
+Treat README.md as public and developer overview, setup, usage, and user-facing context only when governance files conflict.
 
 ## Critical Bootstrap Floor
 
@@ -18,6 +18,7 @@ Treat README.md as overview/install/user context only when governance files conf
 - For UI scope, include a one-line Motion/Palette Decision in the Bootstrap Receipt; product categories are heuristics, not style presets.
 - For UI scope, create or refine `docs/DESIGN.md` and `docs/design-intent.json` before UI implementation.
 - For documentation-first requests, create or refine required project docs in English by default and do not write application, firmware, or UI code until the user asks or approves.
+- Create or refine root README.md as the public and developer entrypoint before implementation.
 - For backend, API, data, auth, error, event, queue, worker, or distributed-system requests, load only relevant global rules from .agent-context/rules/ ([link](../.agent-context/rules)).
 - For ecosystem, framework, dependency, or Docker claims, perform live web research.
 - Resolve runtime choices from project evidence and live official documentation; resolve structural planning from constraints and architecture boundaries.

package/.github/copilot-instructions.md

@@ -2,12 +2,12 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 8a232b1dc9792849a9290898ef40dfff730c13cd0b443d217c0590ced04ed946
+Canonical Snapshot SHA256: c66b5dfe48a25f0df297a1681aa6bab572da95d2201f09abf3767d38a2934591
 
 This repository is governed by a strict instruction contract.
 Use [.instructions.md](../.instructions.md) as the canonical policy source.
 Use .agent-context/ for technical rules, prompts, checklists, policies, and state.
-Treat README.md as overview/install/user context only when governance files conflict.
+Treat README.md as public and developer overview, setup, usage, and user-facing context only when governance files conflict.
 
 ## Critical Bootstrap Floor
 
@@ -18,6 +18,7 @@ Treat README.md as overview/install/user context only when governance files conf
 - For UI scope, include a one-line Motion/Palette Decision in the Bootstrap Receipt; product categories are heuristics, not style presets.
 - For UI scope, create or refine `docs/DESIGN.md` and `docs/design-intent.json` before UI implementation.
 - For documentation-first requests, create or refine required project docs in English by default and do not write application, firmware, or UI code until the user asks or approves.
+- Create or refine root README.md as the public and developer entrypoint before implementation.
 - For backend, API, data, auth, error, event, queue, worker, or distributed-system requests, load only relevant global rules from .agent-context/rules/ ([link](../.agent-context/rules)).
 - For ecosystem, framework, dependency, or Docker claims, perform live web research.
 - Resolve runtime choices from project evidence and live official documentation; resolve structural planning from constraints and architecture boundaries.

package/.github/instructions/agentic-senior-core.instructions.md

@@ -6,12 +6,12 @@ applyTo: "**"
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 8a232b1dc9792849a9290898ef40dfff730c13cd0b443d217c0590ced04ed946
+Canonical Snapshot SHA256: c66b5dfe48a25f0df297a1681aa6bab572da95d2201f09abf3767d38a2934591
 
 This repository is governed by a strict instruction contract.
 Use [.instructions.md](../../.instructions.md) as the canonical policy source.
 Use .agent-context/ for technical rules, prompts, checklists, policies, and state.
-Treat README.md as overview/install/user context only when governance files conflict.
+Treat README.md as public and developer overview, setup, usage, and user-facing context only when governance files conflict.
 
 ## Critical Bootstrap Floor
 
@@ -22,6 +22,7 @@ Treat README.md as overview/install/user context only when governance files conf
 - For UI scope, include a one-line Motion/Palette Decision in the Bootstrap Receipt; product categories are heuristics, not style presets.
 - For UI scope, create or refine `docs/DESIGN.md` and `docs/design-intent.json` before UI implementation.
 - For documentation-first requests, create or refine required project docs in English by default and do not write application, firmware, or UI code until the user asks or approves.
+- Create or refine root README.md as the public and developer entrypoint before implementation.
 - For backend, API, data, auth, error, event, queue, worker, or distributed-system requests, load only relevant global rules from .agent-context/rules/ ([link](../../.agent-context/rules)).
 - For ecosystem, framework, dependency, or Docker claims, perform live web research.
 - Resolve runtime choices from project evidence and live official documentation; resolve structural planning from constraints and architecture boundaries.

package/.instructions.md

@@ -10,7 +10,7 @@ Act as a Principal Engineer. Ship maintainable, validated, production-ready work
 
 This repository is governed by a strict instruction contract.
 
-Use `.instructions.md` as the canonical baseline. Use `.agent-context/` as technical authority for rules, prompts, checklists, state, and policies. Use `README.md` only for overview, setup, and user-facing context when stricter governance files conflict.
+Use `.instructions.md` as the canonical baseline. Use `.agent-context/` as technical authority for rules, prompts, checklists, state, and policies. 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.
@@ -44,7 +44,7 @@ Load only relevant rule files. Do not read the entire rule directory by default.
 
 Available rules: `naming-conv.md`, `architecture.md`, `security.md`, `performance.md`, `error-handling.md`, `testing.md`, `git-workflow.md`, `efficiency-vs-hype.md`, `api-docs.md`, `microservices.md`, `event-driven.md`, `database-design.md`, `realtime.md`, `frontend-architecture.md`, `docker-runtime.md`.
 
-For Docker or Compose work, load `docker-runtime.md` and verify the latest official Docker docs before authoring container assets. For framework or package setup work, use the latest stable compatible dependency set and official setup flow unless a documented compatibility constraint blocks it. 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. 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.
 
 Backend/API routing:
 - Data/schema/persistence: `architecture.md`, `database-design.md`, `performance.md`, `testing.md`.
@@ -59,13 +59,13 @@ Use the union once when scopes overlap. Do not create framework-specific governa
 
 Runtime Decision Signals come from project context, repo evidence, and live research. Runtime signals are evidence gates, not style cues or popularity rankings.
 
-For fresh projects, recommend runtime/framework from the brief, constraints, and live official docs before coding. For existing projects, treat detected markers as evidence only. Ignore pattern frequency, external rankings, and remembered defaults.
+For fresh projects, recommend runtime/framework from the brief, constraints, and live official docs before coding. For existing projects, treat detected markers as evidence only. Ignore pattern frequency, external rankings, and remembered defaults. Do not default web projects to Next.js, Tailwind-only styling, shadcn/ui, Vite, or any familiar web stack by habit, and do not avoid them because of this guard when they are the strongest project fit.
 
 ### Layer 3: Structural Planning Signals
 
 Structural Planning Signals use dynamic structural planning from repo context, docs, runtime constraints, and live research. Structural planning signals are not a hard whitelist.
 
-For new projects or modules, extract constraints, boundaries, and required docs first. Do not silently choose frameworks or architecture from offline heuristics. If runtime or architecture is unresolved, produce a short recommendation from evidence and live official documentation before coding.
+For new projects or modules, extract constraints, boundaries, and required docs first. Do not silently choose frameworks or architecture from offline heuristics. If runtime or architecture is unresolved, produce a short recommendation from evidence and live official documentation before coding. Compare at least one plausible alternative when the strongest-looking option is a familiar web default and the user did not explicitly choose it.
 
 ### Layer 4: Execution Contracts
 
@@ -97,7 +97,7 @@ Use `.agent-context/policies/` for quality gates, release thresholds, and audit
 
 ### Layer 9: Project Context
 
-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/` when present: `project-brief.md`, `architecture-decision-record.md`, `database-schema.md`, `api-contract.md`, `flow-overview.md`, `DESIGN.md`, `design-intent.json`.
 
 ## Mandatory Triggers
 
@@ -106,7 +106,7 @@ Use `docs/` when present: `project-brief.md`, `architecture-decision-record.md`,
 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: `docs/project-brief.md`, `docs/architecture-decision-record.md`, `docs/flow-overview.md`, `docs/api-contract.md` for APIs/firmware/CLI/web 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/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.
 3. Write formal project docs in English by default unless the user asks otherwise.
 4. 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.
 
@@ -148,6 +148,8 @@ Trigger: ui, ux, layout, screen, tailwind, frontend, redesign.
 6. Generate or refine `docs/DESIGN.md` plus `docs/design-intent.json` before UI implementation.
 7. Keep context isolated; do not eagerly load unrelated backend-only rules.
 8. In UI Design Mode, choose the ambition level proactively. For broad screens or redesigns, treat expressive motion, spatial hierarchy, distinctive composition, and product-specific interaction as the baseline even when the user did not say "rich"; 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.
 
 ## Reasoning Chain
 
@@ -165,7 +167,7 @@ Why Required: [project protection]
 Never claim done without:
 1. Relevant rules applied.
 2. PR and architecture checklists considered.
-3. Universal SOP gates satisfied: `docs/architecture-decision-record.md`, plus `docs/DESIGN.md` and `docs/design-intent.json` for UI scope.
+3. Universal SOP gates satisfied: public and developer root `README.md`; `docs/architecture-decision-record.md`; plus `docs/DESIGN.md` and `docs/design-intent.json` 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. MCP validation passed through `npm run validate`.
 

package/.windsurf/rules/agentic-senior-core.md

@@ -2,12 +2,12 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 8a232b1dc9792849a9290898ef40dfff730c13cd0b443d217c0590ced04ed946
+Canonical Snapshot SHA256: c66b5dfe48a25f0df297a1681aa6bab572da95d2201f09abf3767d38a2934591
 
 This repository is governed by a strict instruction contract.
 Use [.instructions.md](../../.instructions.md) as the canonical policy source.
 Use .agent-context/ for technical rules, prompts, checklists, policies, and state.
-Treat README.md as overview/install/user context only when governance files conflict.
+Treat README.md as public and developer overview, setup, usage, and user-facing context only when governance files conflict.
 
 ## Critical Bootstrap Floor
 
@@ -18,6 +18,7 @@ Treat README.md as overview/install/user context only when governance files conf
 - For UI scope, include a one-line Motion/Palette Decision in the Bootstrap Receipt; product categories are heuristics, not style presets.
 - For UI scope, create or refine `docs/DESIGN.md` and `docs/design-intent.json` before UI implementation.
 - For documentation-first requests, create or refine required project docs in English by default and do not write application, firmware, or UI code until the user asks or approves.
+- Create or refine root README.md as the public and developer entrypoint before implementation.
 - For backend, API, data, auth, error, event, queue, worker, or distributed-system requests, load only relevant global rules from .agent-context/rules/ ([link](../../.agent-context/rules)).
 - For ecosystem, framework, dependency, or Docker claims, perform live web research.
 - Resolve runtime choices from project evidence and live official documentation; resolve structural planning from constraints and architecture boundaries.

package/.windsurfrules

@@ -1,6 +1,6 @@
 # .windsurfrules - Legacy Thin Adapter
 
-Generated by Agentic-Senior-Core CLI v3.0.44
+Generated by Agentic-Senior-Core CLI v3.0.46
 Adapter Mode: legacy-thin
 Adapter Source: .agent-instructions.md when present; fallback .instructions.md
 Canonical baseline: .instructions.md

package/AGENTS.md

@@ -2,12 +2,12 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 8a232b1dc9792849a9290898ef40dfff730c13cd0b443d217c0590ced04ed946
+Canonical Snapshot SHA256: c66b5dfe48a25f0df297a1681aa6bab572da95d2201f09abf3767d38a2934591
 
 This repository is governed by a strict instruction contract.
 Use [.instructions.md](.instructions.md) as the canonical policy source.
 Use .agent-context/ for technical rules, prompts, checklists, policies, and state.
-Treat README.md as overview/install/user context only when governance files conflict.
+Treat README.md as public and developer overview, setup, usage, and user-facing context only when governance files conflict.
 
 ## Critical Bootstrap Floor
 
@@ -18,6 +18,7 @@ Treat README.md as overview/install/user context only when governance files conf
 - For UI scope, include a one-line Motion/Palette Decision in the Bootstrap Receipt; product categories are heuristics, not style presets.
 - For UI scope, create or refine `docs/DESIGN.md` and `docs/design-intent.json` before UI implementation.
 - For documentation-first requests, create or refine required project docs in English by default and do not write application, firmware, or UI code until the user asks or approves.
+- Create or refine root README.md as the public and developer entrypoint before implementation.
 - For backend, API, data, auth, error, event, queue, worker, or distributed-system requests, load only relevant global rules from .agent-context/rules/ ([link](.agent-context/rules)).
 - For ecosystem, framework, dependency, or Docker claims, perform live web research.
 - Resolve runtime choices from project evidence and live official documentation; resolve structural planning from constraints and architecture boundaries.

package/CLAUDE.md

@@ -2,12 +2,12 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 8a232b1dc9792849a9290898ef40dfff730c13cd0b443d217c0590ced04ed946
+Canonical Snapshot SHA256: c66b5dfe48a25f0df297a1681aa6bab572da95d2201f09abf3767d38a2934591
 
 This repository is governed by a strict instruction contract.
 Use [.instructions.md](.instructions.md) as the canonical policy source.
 Use .agent-context/ for technical rules, prompts, checklists, policies, and state.
-Treat README.md as overview/install/user context only when governance files conflict.
+Treat README.md as public and developer overview, setup, usage, and user-facing context only when governance files conflict.
 
 ## Critical Bootstrap Floor
 
@@ -18,6 +18,7 @@ Treat README.md as overview/install/user context only when governance files conf
 - For UI scope, include a one-line Motion/Palette Decision in the Bootstrap Receipt; product categories are heuristics, not style presets.
 - For UI scope, create or refine `docs/DESIGN.md` and `docs/design-intent.json` before UI implementation.
 - For documentation-first requests, create or refine required project docs in English by default and do not write application, firmware, or UI code until the user asks or approves.
+- Create or refine root README.md as the public and developer entrypoint before implementation.
 - For backend, API, data, auth, error, event, queue, worker, or distributed-system requests, load only relevant global rules from .agent-context/rules/ ([link](.agent-context/rules)).
 - For ecosystem, framework, dependency, or Docker claims, perform live web research.
 - Resolve runtime choices from project evidence and live official documentation; resolve structural planning from constraints and architecture boundaries.

package/GEMINI.md

@@ -2,12 +2,12 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 8a232b1dc9792849a9290898ef40dfff730c13cd0b443d217c0590ced04ed946
+Canonical Snapshot SHA256: c66b5dfe48a25f0df297a1681aa6bab572da95d2201f09abf3767d38a2934591
 
 This repository is governed by a strict instruction contract.
 Use [.instructions.md](.instructions.md) as the canonical policy source.
 Use .agent-context/ for technical rules, prompts, checklists, policies, and state.
-Treat README.md as overview/install/user context only when governance files conflict.
+Treat README.md as public and developer overview, setup, usage, and user-facing context only when governance files conflict.
 
 ## Critical Bootstrap Floor
 
@@ -18,6 +18,7 @@ Treat README.md as overview/install/user context only when governance files conf
 - For UI scope, include a one-line Motion/Palette Decision in the Bootstrap Receipt; product categories are heuristics, not style presets.
 - For UI scope, create or refine `docs/DESIGN.md` and `docs/design-intent.json` before UI implementation.
 - For documentation-first requests, create or refine required project docs in English by default and do not write application, firmware, or UI code until the user asks or approves.
+- Create or refine root README.md as the public and developer entrypoint before implementation.
 - For backend, API, data, auth, error, event, queue, worker, or distributed-system requests, load only relevant global rules from .agent-context/rules/ ([link](.agent-context/rules)).
 - For ecosystem, framework, dependency, or Docker claims, perform live web research.
 - Resolve runtime choices from project evidence and live official documentation; resolve structural planning from constraints and architecture boundaries.

package/lib/cli/compiler.mjs

@@ -422,7 +422,9 @@ export async function buildCompiledRulesContent({
       '3. .agent-context/prompts/review-code.md -> review, audit, check, analyze',
       '4. .agent-context/prompts/bootstrap-design.md -> ui, ux, layout, screen, tailwind, frontend, redesign',
       'Documentation-first policy:',
-      '- Create or refine required project docs before implementation: docs/project-brief.md, docs/architecture-decision-record.md, docs/flow-overview.md, docs/api-contract.md when APIs, firmware endpoints, CLI commands, or web application flows exist, docs/database-schema.md when persistent data exists, and docs/DESIGN.md plus docs/design-intent.json for UI scope.',
+      '- Create or refine required project docs before implementation: README.md for every fresh or existing project; docs/project-brief.md; docs/architecture-decision-record.md; docs/flow-overview.md; docs/api-contract.md when APIs, firmware endpoints, CLI commands, or web application flows exist; docs/database-schema.md when persistent data exists; and docs/DESIGN.md plus docs/design-intent.json for UI scope.',
+      '- Keep README.md public and developer friendly, including for private projects: explain what the project is, who it is for, setup, usage, configuration, and links to deeper docs. Do not put secrets, internal agent notes, private reasoning, or governance policy dumps in it.',
+      '- Keep docs complete but compact. Add extra docs files only for stable, distinct, or long workflows such as hardware setup, deployment, operations, testing validation, or troubleshooting.',
       '- Write formal project docs in English by default unless the user explicitly asks for another documentation language.',
       '- For docs-only/docs-first requests, do not write application, firmware, or UI code until the user asks or approves an implementation plan.',
       'UI trigger policy:',
@@ -543,6 +545,7 @@ export async function buildCompiledRulesContent({
   const hasBootstrapDesignPrompt = await pathExists(bootstrapDesignPromptPath);
 
   if (await pathExists(projectBriefPath)) {
+    const hasRootReadme = await pathExists(path.join(resolvedTargetDirectoryPath, 'README.md'));
     const projectDocsEntries = ['project-brief.md'];
     const candidateDocFileNames = [
       'architecture-decision-record.md',
@@ -565,15 +568,18 @@ export async function buildCompiledRulesContent({
         '## LAYER 9: PROJECT CONTEXT (MANDATORY)',
         'These documents describe the specific project being built.',
         'Read them before writing any application code:',
-        ...projectDocsEntries.map((docFileName, docIndex) => `${docIndex + 1}. docs/${docFileName}`),
+        ...(hasRootReadme ? ['1. README.md'] : []),
+        ...projectDocsEntries.map((docFileName, docIndex) => `${(hasRootReadme ? 2 : 1) + docIndex}. docs/${docFileName}`),
         '',
         'Universal SOP hard block policy:',
+        '- README.md must exist and read as a public and developer entrypoint.',
         '- Stop implementation if docs/project-brief.md is missing.',
         '- Stop implementation if docs/architecture-decision-record.md (alias: docs/Architecture-Decision-Record.md) is missing.',
         '- Stop implementation if docs/flow-overview.md is missing.',
         '- If the product uses persistent data, docs/database-schema.md must exist before coding continues.',
         '- If the product exposes API or web application flows, docs/api-contract.md must exist before coding continues.',
         '- For UI scope, stop implementation if docs/DESIGN.md or docs/design-intent.json is missing.',
+        '- Keep README.md overview-level, public, and developer friendly; do not put secrets, internal agent notes, private reasoning, or governance policy dumps in it.',
         '- Materialize missing docs first, then continue coding.',
         '- Bootstrap missing docs from real repo evidence and the latest user request. Do not write generic placeholder templates.',
         '- Separate confirmed facts from assumptions and end each major explanation with the next validation action.',
@@ -583,7 +589,7 @@ export async function buildCompiledRulesContent({
         'Latest user prompt defines current feature scope and product direction.',
         'Treat requested features as dynamic, but keep stack/database/auth constraints consistent',
         'with project docs unless the user explicitly asks for a migration.',
-        'When scope changes, implement the new request and update docs/* in the same change',
+        'When scope changes, implement the new request and update README.md plus docs/* in the same change when documented context changes',
         'so generated context stays aligned with the codebase.',
         'Update them as the project evolves. They are living references, not frozen specs.',
       ].join('\n')
@@ -605,6 +611,7 @@ export async function buildCompiledRulesContent({
         ...bootstrapPromptEntries.map((promptFilePath, promptIndex) => `${promptIndex + 1}. ${promptFilePath}`),
         '',
         'Bootstrap policy:',
+        '- Create README.md as a public and developer entrypoint before coding continues.',
         '- Hard block: do not write application code until docs/project-brief.md and docs/architecture-decision-record.md exist.',
         '- docs/flow-overview.md must also exist before coding continues.',
         '- Add docs/database-schema.md when persistent data is involved.',

package/lib/cli/project-scaffolder/design-contract/validation.mjs

@@ -236,7 +236,8 @@ export function validateDesignIntentContract(designIntentContract) {
       !Array.isArray(conceptualAnchor.sourceDomains)
       || conceptualAnchor.sourceDomains.length < 4
       || !conceptualAnchor.sourceDomains.includes('complex-physical-engineering')
-      || !conceptualAnchor.sourceDomains.includes('cinematic-spatial-interface')
+      || !conceptualAnchor.sourceDomains.includes('cinematic-behavior-and-transition-systems')
+      || !conceptualAnchor.sourceDomains.includes('workflow-and-custody-systems')
       || !conceptualAnchor.sourceDomains.includes('premium-interactive-web-experiences')
     ) {
       validationErrors.push('designIntent.conceptualAnchor.sourceDomains must list broad non-template anchor domains.');

package/lib/cli/project-scaffolder/design-contract.mjs

@@ -29,6 +29,12 @@ const GENERICITY_DRIFT_SIGNALS = [
   'literal-anchor-artifacts-used-as-required-ui-chrome',
   'candidate-signature-move-treated-as-locked-implementation',
   'library-theme-tokens-drive-visual-language',
+  'spatial-room-anchor-used-by-habit',
+  'place-metaphor-used-as-layout-model-without-product-function',
+  'external-website-reference-copied-as-style',
+  'tailwind-only-or-component-kit-used-as-neutrality-claim',
+  'framework-selected-by-familiarity-instead-of-evidence',
+  'manual-framework-scaffold-used-when-official-setup-fits',
 ];
 
 const FORBIDDEN_PATTERN_SIGNALS = [
@@ -50,6 +56,9 @@ const VALID_BOLD_SIGNALS = [
   'headless-or-component-primitive-restyled-to-product-language',
   'responsive-recomposition-by-task-priority',
   'purposeful-motion-with-reduced-motion-path',
+  'non-spatial-product-anchor-or-workflow-mechanism',
+  'official-scaffolder-used-for-supported-project-shape',
+  'framework-choice-compared-against-plausible-alternative',
 ];
 
 export function shouldBootstrapDesignDocument(discoveryAnswers, initContext) {
@@ -202,11 +211,14 @@ function buildDesignIntentContractObject({
         'component-kit-theme-mapping',
         'signature-move-implementation',
         'literal-anchor-artifacts',
+        'spatial-metaphor-and-place-language',
       ],
       tokenLockingRule: 'Semantic roles are required, but exact primitive values stay flexible until repo evidence, accessibility validation, implementation constraints, or explicit user approval locks them.',
       signatureMovePolicy: 'Record the required experience outcome separately from candidate implementation moves; replace a candidate move when another move better fits the product.',
       libraryVisualLanguagePolicy: 'Libraries supply behavior, accessibility, primitives, and delivery speed; they must not dictate final composition, theme, morphology, or visual language.',
       literalAnchorPolicy: 'Translate anchors into workflow, hierarchy, density, typography, material behavior, state language, and interaction grammar before requiring literal props, marks, or chrome.',
+      spatialMetaphorPolicy: 'Do not default anchors to room, darkroom, counting room, control room, war room, studio, lab, cockpit, or command center. Use place metaphors only when the product truly depends on a physical place model.',
+      externalInspirationPolicy: 'External websites and examples are candidate evidence for constraints, mechanics, and quality bars; do not copy their layout rhythm, palette, component skin, brand posture, or visual metaphor.',
     },
     conceptualAnchor: {
       mode: 'required-when-no-external-research',
@@ -227,6 +239,8 @@ function buildDesignIntentContractObject({
         preferDistinctiveOverSafe: true,
         doNotRevealHiddenCandidateList: true,
         outputOnlyChosenAnchor: true,
+        avoidSpatialPlaceMetaphorByDefault: true,
+        preferMechanismOverPlace: true,
       },
       creativeCommitmentPolicy: {
         requiredBeforeComplianceReview: true,
@@ -246,12 +260,23 @@ function buildDesignIntentContractObject({
         'saas-shell',
         'minimalist-interface',
         'safe-admin-layout',
+        'room',
+        'darkroom',
+        'counting-room',
+        'control-room',
+        'war-room',
+        'studio',
+        'lab',
+        'cockpit',
+        'command-center',
       ],
       sourceDomains: [
         'complex-physical-engineering',
-        'cinematic-spatial-interface',
+        'cinematic-behavior-and-transition-systems',
         'experimental-editorial-structure',
         'scientific-instrumentation',
+        'workflow-and-custody-systems',
+        'material-artifacts-and-instruments',
         'premium-interactive-web-experiences',
       ],
       visualRiskBudget: {
@@ -266,6 +291,12 @@ function buildDesignIntentContractObject({
         allowedLiteralUse: 'Only use literal anchor artifacts when they serve a named product function, control, state, or task overlay.',
         forbiddenLiteralUse: 'Do not turn anchor artifacts into decorative wallpaper, required chrome, default texture, or unavoidable theme props.',
       },
+      spatialAutopilotPolicy: {
+        forbiddenHabitTerms: ['room', 'darkroom', 'counting-room', 'control-room', 'war-room', 'studio', 'lab', 'cockpit', 'command-center'],
+        allowedOnlyWhen: 'The product has a real physical place model, operational environment, or user workflow that depends on that place metaphor.',
+        replacementPreference: 'Use artifacts, custody flows, instruments, data behaviors, material systems, editorial systems, service rituals, or interaction mechanisms.',
+        reviewQuestion: 'Could this anchor still work if the word "room" was removed? If not, revise before UI code.',
+      },
       requiredDerivedAxes: [
         'typography',
         'morphology',
@@ -370,7 +401,9 @@ function buildDesignIntentContractObject({
         sourceUrl: null,
         stableVersion: null,
         fallbackIfUnavailable: 'Use native CSS, browser APIs, or existing dependencies.',
-        selectionPolicy: 'Do not default to shadcn, native-only, Tailwind-only, or dependency avoidance by habit.',
+        selectionPolicy: 'Do not default to shadcn, native-only, Tailwind-only, or dependency avoidance by habit; do not avoid them out of guardrail fear when they fit.',
+        officialScaffolderPolicy: 'For fresh projects, prefer official setup commands when they create the supported project shape; manual assembly requires a documented repo, learning, prototype, or architecture reason.',
+        frameworkNeutralityPolicy: 'Next.js, Vite, Astro, React Router, SvelteKit, Laravel, and plain HTML are candidates, not defaults or forbidden choices. Compare at least one plausible alternative when no framework is user-constrained, then choose the technology that removes bottlenecks for this project.',
       },
     ],
     mathSystems: {
@@ -687,9 +720,12 @@ function buildDesignIntentContractObject({
       requireExplicitContinuityApproval: true,
       forbidCarryoverWhenUnapproved: true,
       approvedExternalConstraintUsage: 'Convert approved external constraints into current-project rules; do not imitate source surfaces.',
+      externalWebsiteReferencePolicy: 'Use outside websites for mechanics, constraints, and quality bar analysis only. Do not copy layout rhythm, palette, component skin, visual metaphor, or brand posture.',
       driftSignals: [
         'palette-reused-without-brief-support',
         'prior-ui-visual-dna-carried-into-reset-request',
+        'room-or-control-room-anchor-repeated-without-product-need',
+        'external-reference-copied-instead-of-translated',
       ],
     },
     forbiddenPatterns: [...FORBIDDEN_PATTERN_SIGNALS],

package/lib/cli/project-scaffolder/prompt-builders.mjs

@@ -44,8 +44,11 @@ export function buildProjectContextBootstrapPrompt({
     ? discoveryAnswers.features.map((feature, featureIndex) => `${featureIndex + 1}. ${feature}`).join('\n')
     : 'Derive the first concrete feature set from the project name, description, and domain. Do not invent arbitrary modules just to fill space.';
 
-  const expectedDocsList = expectedDocFileNames
-    .map((fileName, fileIndex) => `${fileIndex + 1}. docs/${fileName}`)
+  const expectedDocsList = [
+    'README.md',
+    ...expectedDocFileNames.map((fileName) => `docs/${fileName}`),
+  ]
+    .map((filePath, fileIndex) => `${fileIndex + 1}. ${filePath}`)
     .join('\n');
 
   return [
@@ -73,7 +76,9 @@ export function buildProjectContextBootstrapPrompt({
     '10. Do not invent modules or architecture layers only to make the docs look complete.',
     '11. If runtime or framework setup is unresolved, recommend the latest stable compatible option from the brief, constraints, and live official documentation before coding. If an official setup flow yields newer, better-supported defaults than manual package assembly, use that path after approval.',
     '12. Treat topology as an agent decision unless the user explicitly constrained it. If monolith fits, explain why. If a service split fits, document the evidence and service boundary logic.',
-    '13. Required docs coverage must include feature plan, architecture rationale, flow, public API or integration contracts when relevant, data model when relevant, UI/design when relevant, security assumptions, testing strategy, runtime/deployment notes, and next validation actions.',
+    '13. Required docs coverage must include a public and developer README entrypoint, feature plan, architecture rationale, flow, public API or integration contracts when relevant, data model when relevant, UI/design when relevant, security assumptions, testing strategy, runtime/deployment notes, and next validation actions.',
+    '14. README.md must be public and developer friendly, including for private projects: what it is, who it is for, setup, core workflow, configuration, and links to deeper docs. Do not include secrets, internal agent notes, private reasoning, or governance policy dumps.',
+    '15. Keep docs complete but compact. Add extra docs files only for stable, distinct, or long workflows such as hardware setup, deployment, operations, testing validation, or troubleshooting.',
     '',
     '## Project Inputs',
     `- Project name: ${discoveryAnswers.projectName}`,
@@ -101,8 +106,9 @@ export function buildProjectContextBootstrapPrompt({
     '1. Create all required docs files listed above with complete Markdown content.',
     '2. Make the docs adaptive to the real repo and prompt context. These are living references, not frozen templates.',
     '3. In docs/project-brief.md and docs/architecture-decision-record.md, include explicit sections for confirmed facts, assumptions to validate, and next validation actions whenever context is incomplete.',
-    '4. Keep content original, specific to this project, and actionable for implementation.',
-    '5. After writing docs, continue coding tasks using these docs as living project context.',
+    '4. Before implementation, use the docs to confirm stack, runtime, architecture, public contracts, data, validation, and delivery assumptions.',
+    '5. Keep content original, specific to this project, and actionable for implementation.',
+    '6. After writing docs, continue coding tasks using these docs as living project context.',
     '',
   ].join('\n');
 }
@@ -208,13 +214,17 @@ export function buildDesignBootstrapPrompt({
     '25. In Dynamic Avant-Garde mode, consider three high-variance anchors, discard the two safest or most predictable options, and output only the chosen anchor.',
     '26. Reject final anchors named dashboard, portal, cards, admin panel, SaaS shell, web app shell, or minimalist interface.',
     '27. Reject anchors described only as modern, clean, premium, expressive, minimal, or bold.',
+    '27a. Do not default anchors to room, darkroom, counting room, control room, war room, studio, lab, cockpit, or command center unless the product genuinely depends on that physical place model.',
+    '27b. Prefer artifacts, custody flows, instruments, data behaviors, material systems, editorial systems, service rituals, or interaction mechanisms over "where the interface lives".',
     '28. Set conceptualAnchor.anchorReference and make derivedTokenLogic.anchorReference match exactly.',
     '29. Fill derivedTokenLogic before code. If a token cannot trace to anchorReference, revise it.',
     '29a. Lock semantic roles before exact values. Do not freeze fonts, color primitives, radius, shadows, or component-kit theme treatment unless repo evidence, accessibility validation, implementation constraints, or explicit user approval requires it.',
     '30. Research current official docs before importing any new UI-related library.',
-    '31. Do not default to shadcn/ui, Tailwind-only, native-only, or any component kit by habit; choose the UI foundation from product fit, accessibility, interaction quality, runtime constraints, and official docs.',
+    '31. Do not default to shadcn/ui, Tailwind-only, native-only, or any component kit by habit, and do not avoid them out of guardrail fear; choose the UI foundation from product fit, accessibility, interaction quality, runtime constraints, and official docs.',
     '32. If research is unavailable, set libraryResearchStatus to pending-verification and use native CSS, browser APIs, or existing dependencies only when they can preserve the intended ambition.',
     '33. Do not reject modern lightweight libraries solely because they add a dependency; package count or vague performance fear is not a blocker by itself.',
+    '33a. Tailwind-first is valid only when the stack, token model, and team workflow support it; pure Tailwind, vanilla CSS, shadcn/ui, or any component kit is not neutral by default and not forbidden by default.',
+    '33b. For fresh framework projects, prefer official setup commands when official docs show they create the supported project shape; manual file assembly requires a repo, prototype, learning, or architecture reason.',
     '34. Define reviewRubric and require genericity findings to name the actual drift signal.',
     '35. Separate taste from failure. Bold accessible work is valid.',
     '36. For zero-based redesign, create visualResetStrategy and reset composition, hierarchy, palette/typography, motion or interaction, and responsive information architecture.',
@@ -222,6 +232,7 @@ export function buildDesignBootstrapPrompt({
     '38. Do not make core user workflows terminal-only unless the product is explicitly a CLI, developer tool, or operational runbook.',
     '39. Separate required experience outcomes from candidate implementation moves. Candidate signature moves are proposals until product evidence, accessibility, or user approval makes them required.',
     '40. Translate conceptual anchors non-literally first. Do not turn anchor artifacts into required chrome, decorative props, wallpaper, or theme objects unless they serve a named product function.',
+    '41. Use external websites and benchmark examples as candidate evidence for constraints, mechanics, and quality bars only; do not copy layout rhythm, palette, component skin, visual metaphor, or brand posture.',
     '',
     '## Creative Ambition Floor',
     'Before implementation, the design contract must name one authored visual bet, one product-derived palette move, one signature motion/spatial/interaction behavior, and one morphology or composition choice that would not appear in a generic AI template.',
@@ -238,6 +249,7 @@ export function buildDesignBootstrapPrompt({
     'If web search is available, verify every new UI, animation, scroll, 3D, canvas, chart, icon, styling, or primitive library against current official docs and record source URL, fetched date, stable compatible version, purpose, risk, and fallback.',
     'If web search is unavailable or fails, set libraryResearchStatus to pending-verification, record LIBRARY_TO_VERIFY notes, and use native CSS, browser APIs, or already-present project dependencies only when they can preserve the intended ambition until verification is possible.',
     'Select UI foundations dynamically. Use ready-made primitives or component kits for mechanics when they fit, but replace library-default visual language with project-specific composition, tokens, motion, state treatment, and morphology.',
+    'For fresh projects, compare the user-constrained or strongest-fit framework against at least one plausible alternative when no framework is explicitly selected. Do not let Next.js or any familiar web stack win by pattern frequency.',
     '',
     '## Project Inputs',
     `- Project name: ${discoveryAnswers.projectName}`,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ryuenn3123/agentic-senior-core",
-  "version": "3.0.44",
+  "version": "3.0.46",
   "type": "module",
   "description": "Force your AI Agent to code like a Staff Engineer, not a Junior.",
   "bin": {

package/scripts/frontend-usability-audit.mjs

@@ -58,7 +58,7 @@ const REQUIRED_FRONTEND_RULE_SNIPPETS = [
   '## Activation',
   '## Authority',
   'Treat `.agent-context/` as design governance authority.',
-  'Treat `README.md` as overview/install/user context only',
+  'Treat `README.md` as public and developer overview, setup, usage, and user-facing context only',
   'Do not choose final style, framework, palette, typography, layout paradigm, or animation library offline.',
   'Keep design continuity opt-in.',
   'Repo evidence outranks memory residue.',

package/scripts/sync-thin-adapters.mjs

@@ -59,7 +59,7 @@ function buildThinAdapter({
     'This repository is governed by a strict instruction contract.',
     `Use [${CANONICAL_SOURCE_PATH}](${canonicalLink}) as the canonical policy source.`,
     'Use .agent-context/ for technical rules, prompts, checklists, policies, and state.',
-    'Treat README.md as overview/install/user context only when governance files conflict.',
+    'Treat README.md as public and developer overview, setup, usage, and user-facing context only when governance files conflict.',
     '',
     '## Critical Bootstrap Floor',
     '',
@@ -70,6 +70,7 @@ function buildThinAdapter({
     '- For UI scope, include a one-line Motion/Palette Decision in the Bootstrap Receipt; product categories are heuristics, not style presets.',
     '- For UI scope, create or refine `docs/DESIGN.md` and `docs/design-intent.json` before UI implementation.',
     '- For documentation-first requests, create or refine required project docs in English by default and do not write application, firmware, or UI code until the user asks or approves.',
+    '- Create or refine root README.md as the public and developer entrypoint before implementation.',
     `- For backend, API, data, auth, error, event, queue, worker, or distributed-system requests, load only relevant global rules from .agent-context/rules/ ([link](${rulesLink})).`,
     '- For ecosystem, framework, dependency, or Docker claims, perform live web research.',
     '- Resolve runtime choices from project evidence and live official documentation; resolve structural planning from constraints and architecture boundaries.',

package/scripts/validate/config.mjs

@@ -195,6 +195,7 @@ export const REQUIRED_UNIVERSAL_SOP_SNIPPETS = [
     path: '.instructions.md',
     snippets: [
       '### 1. Documentation-First Mode',
+      'root `README.md` for every fresh or existing project',
       'Stop after documentation when the user only asked for docs.',
       'Do not write application, firmware, or UI code',
     ],
@@ -203,6 +204,7 @@ export const REQUIRED_UNIVERSAL_SOP_SNIPPETS = [
     path: '.agent-context/rules/architecture.md',
     snippets: [
       '## Universal SOP Baseline (Mandatory)',
+      'Root `README.md` must exist for every fresh or existing project',
       'Security and testing are non-negotiable baseline requirements.',
       'If required project context docs are missing, stop implementation and bootstrap docs before writing application code.',
     ],
@@ -211,6 +213,7 @@ export const REQUIRED_UNIVERSAL_SOP_SNIPPETS = [
     path: '.agent-context/prompts/init-project.md',
     snippets: [
       '## Documentation-First Requests',
+      'root `README.md` for every fresh or existing project',
       'Stop after docs when the user only asked for docs.',
       'Write formal project docs in English by default',
     ],
@@ -219,6 +222,7 @@ export const REQUIRED_UNIVERSAL_SOP_SNIPPETS = [
     path: '.agent-context/review-checklists/pr-checklist.md',
     snippets: [
       '### 15. Universal SOP Consolidation',
+      'Coding flow is blocked if root `README.md` is missing',
       'Coding flow is blocked if `docs/architecture-decision-record.md` (or `docs/Architecture-Decision-Record.md`) is missing',
       'UI implementation flow is blocked if `docs/DESIGN.md` or `docs/design-intent.json` is missing',
     ],
@@ -226,21 +230,23 @@ export const REQUIRED_UNIVERSAL_SOP_SNIPPETS = [
   {
     path: '.agent-context/prompts/review-code.md',
     snippets: [
-      '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`).',
+      'Enforce Universal SOP hard gate: block coding flow when required project docs are missing (root `README.md`; `docs/architecture-decision-record.md`; and for UI scope `docs/DESIGN.md` plus `docs/design-intent.json`).',
     ],
   },
   {
     path: '.agent-context/prompts/refactor.md',
     snippets: [
-      '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.',
+      '6. Enforce Universal SOP hard gate: stop implementation if root `README.md` is missing, if `docs/architecture-decision-record.md` is missing, or for UI scope if `docs/DESIGN.md` or `docs/design-intent.json` is missing.',
     ],
   },
   {
     path: 'lib/cli/compiler.mjs',
     snippets: [
       'Universal SOP hard block policy:',
+      'README.md must exist and read as a public and developer entrypoint',
       'Hard block: do not write application code until docs/project-brief.md and docs/architecture-decision-record.md exist.',
       'Documentation-first policy:',
+      'Keep README.md public and developer friendly',
       'For docs-only/docs-first requests, do not write application, firmware, or UI code until the user asks or approves an implementation plan.',
       'For UI scope: if docs/DESIGN.md or docs/design-intent.json is missing, execute bootstrap-design prompt before implementing UI surfaces.',
     ],