@ryuenn3123/agentic-senior-core 3.0.13 → 3.0.15

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

@@ -11,6 +11,7 @@ UI Design Mode is context-isolated by default:
 - Load [AGENTS.md](../../AGENTS.md), [frontend-architecture.md](../rules/frontend-architecture.md), this prompt, UI-relevant state files, current UI code, and existing design docs first.
 - Do not eagerly load backend-only rules such as [database-design.md](../rules/database-design.md), [docker-runtime.md](../rules/docker-runtime.md), or [microservices.md](../rules/microservices.md) unless the task explicitly crosses those boundaries.
 - Treat UI consistency, accessibility, and cross-viewport adaptation as first-class constraints, not cosmetic afterthoughts.
+- Start the visual language from the current project context, not from prior website references or remembered layouts from earlier chats.
 
 The agent must:
 1. Read [AGENTS.md](../../AGENTS.md) for project context and team roles.
@@ -19,12 +20,15 @@ The agent must:
 4. When analyzing an existing UI codebase, inspect low-cost evidence such as hardcoded color density, prop-drilling candidates, and breakpoint chaos before declaring the current design direction healthy.
 5. If [docs/DESIGN.md](../../docs/DESIGN.md) or `docs/design-intent.json` already exists, check for drift and improve them instead of rewriting blindly.
 6. If context is incomplete, write explicit assumptions and reversible design bets instead of defaulting to generic SaaS output.
-7. Explore multiple plausible design directions internally, then commit to one cohesive direction with clear rationale tied to the product context.
+7. Explore multiple plausible design directions internally, then commit to one cohesive direction with clear rationale tied to the product context and at least one memorable signature move.
 8. Treat any example structure or stylistic inspiration as non-normative. Use it only to judge depth and clarity, never to copy a visual language directly.
 9. All references to docs or rules must be clickable markdown links.
 10. Responsive work must adapt layout, navigation, density, and task order across viewports. Shrinking desktop layouts is not enough.
-11. Motion is allowed when it improves feedback, continuity, or spatial understanding. Do not flatten everything into static screens, but do reject decorative motion with no product value.
+11. Motion can be bold, cinematic, or highly expressive when it improves memorability, hierarchy, feedback, or perceived product quality. Do not flatten everything into static screens. Optimize motion first, and only reject it when it harms clarity, accessibility, or runtime performance.
 12. Define how core components morph across interaction states and viewports. Component quality is not only visual styling; it includes behavior under hover, focus, active, loading, error, and constrained layouts.
+13. Do not reuse a color palette, component skin, or motion signature from prior chats, memories, or unrelated projects unless current repo evidence or the active brand brief explicitly asks for that continuity.
+14. Treat prior website memory, old portfolio styles, and remembered screenshots as tainted context unless the user explicitly asks to continue or evolve that specific visual system.
+15. Do not default to balanced card grids, soft startup gradients, safe centered heroes, or neutral dashboard chrome unless the product context explicitly justifies them.
 
 Required `docs/DESIGN.md` sections:
 1. Design Intent and Product Personality
@@ -66,6 +70,9 @@ Output:
 - `docs/design-intent.json` must also include `motionSystem` and `componentMorphology` so future UI work preserves state behavior and purposeful motion without collapsing into generic static output.
 - Color intent must be defined in a perceptual or relational color model first. Hex values may appear only as implementation derivatives.
 - The contract must encode viewport mutation rules, not just breakpoint names.
-- Motion guidance must preserve creativity: allow meaningful animation, define reduced-motion behavior, and keep choreography fast, intentional, and performant.
+- Motion guidance must preserve creativity: allow meaningful animation, define reduced-motion behavior, and optimize choreography instead of suppressing it by default.
+- Color direction must come from the current project context. Similarity to prior unrelated projects is drift unless the brief or repo evidence explicitly supports it.
+- If no approved reference system exists, synthesize the design from zero using current product context, constraints, and content only.
+- The resulting system should feel authored and recognizable in screenshots, not politely interchangeable with common template kits.
 - Use practical, modern, accessible language grounded in the project, not generic SaaS defaults or copycat brand systems.
 - Wait for user approval before generating Figma or code assets.

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

@@ -9,6 +9,8 @@ When a new project is created or initialized, the agent should automatically:
 1. Read [AGENTS.md](../../AGENTS.md) to understand available roles and knowledge base.
 2. Scan all files in [.agent-context/rules/](../rules/) for mandatory engineering standards.
 3. Review dynamic stack and architecture signals from [.agent-context/state/onboarding-report.json](../state/onboarding-report.json), [.agent-context/state/stack-research-snapshot.json](../state/stack-research-snapshot.json), available stack and blueprint sources, and task constraints.
+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. Prefer latest stable compatible images, dependencies, and Compose syntax first; only step down after documenting why.
+5. For framework or package setup, prefer the latest stable compatible dependency set and official framework setup flow first. Only pin older versions after documenting the exact compatibility reason.
 
 ## Architect Mode (Recommended)
 If the user describes a project or feature, the agent should:
@@ -32,6 +34,8 @@ If the user specifies a framework/blueprint, the agent should:
 	- Every file must follow [naming conventions](../rules/naming-conv.md)
 	- Every module must follow [architecture.md](../rules/architecture.md)
 	- Every dependency must be justified per [efficiency-vs-hype.md](../rules/efficiency-vs-hype.md)
+	- Prefer official framework setup commands or canonical starter flows when they produce newer, better-supported dependency defaults than manual package assembly
+	- 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.
 
 ## Stacks & Blueprints Reference
 See [.agent-context/state/onboarding-report.json](../state/onboarding-report.json), [.cursorrules](../../.cursorrules), and [.windsurfrules](../../.windsurfrules) for the latest shipped stack and blueprint context.

package/.agent-context/rules/docker-runtime.md

@@ -2,10 +2,18 @@
 
 Use this rule when Docker is enabled in project context.
 
+## 0. Latest Official Docker Guidance First
+- Before generating or changing Dockerfiles, Compose files, or container runbooks, verify the latest official Docker documentation first.
+- Prefer official Docker sources such as [Docker Compose Quickstart](https://docs.docker.com/compose/gettingstarted/), [Compose file reference](https://docs.docker.com/reference/compose-file/), and [Dockerfile best practices](https://docs.docker.com/build/building/best-practices/).
+- Prefer current `docker compose` workflows and `compose.yaml`. Do not default to legacy `docker-compose` commands or stale file naming unless backward compatibility is a stated project requirement.
+- Do not add the top-level Compose `version` field by default. The current Compose reference treats it as obsolete. Use it only when a compatibility requirement is explicit and documented.
+- Prefer the latest stable compatible Docker base image, package-manager flow, and Compose syntax first. If the latest compatible path fails, step down intentionally and document the exact reason for the fallback.
+
 ## 1. Dynamic Generation Only
 - Do not copy generic Docker templates blindly.
 - Generate Docker assets based on actual stack, package manager, and runtime dependencies in the repository.
 - Re-evaluate Docker instructions when dependencies, build tools, or runtime assumptions change.
+- Prefer the latest stable compatible dependency line first. If an older dependency or base image must be pinned, explain the runtime or compatibility constraint that forced it.
 
 ## 2. Separate Development and Production Lanes
 - Development lane and production lane are separate concerns.
@@ -17,13 +25,17 @@ Use this rule when Docker is enabled in project context.
 - Use multi-stage builds for production images when possible.
 - Avoid baking secrets into image layers.
 - Keep runtime image free from build-only tooling.
+- Prefer fresh base-image validation with `docker build --pull` and use `--no-cache` when a clean dependency refresh is required.
+- Keep a `.dockerignore` strategy in mind so build contexts stay small and do not leak unnecessary files into the image.
 
 ## 4. Operational Clarity
 - Docker instructions must document expected entrypoint and exposed ports.
 - Local development command and production deployment command must be explicit.
 - If Docker is not selected for the project, do not force containerization tasks.
+- If Compose is used, document which file is the primary entrypoint, which services are dev-only versus production-facing, and why the chosen layout matches the current Docker docs rather than a legacy blog pattern.
 
 ## 5. Review Requirements
 - Verify the generated Docker workflow matches selected runtime environment (Linux/WSL, Windows, macOS).
 - Verify development and production instructions are not mixed into one unsafe image path.
 - Ensure API and service health checks are compatible with container startup behavior.
+- When Docker choices depend on official docs or release behavior, cite the Docker source and verification date in the generated docs or explanation so the next update can refresh them safely.

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

@@ -3,6 +3,13 @@
 > Every dependency is a liability. Every `npm install` is a trust decision.
 > The best dependency is the one you don't need.
 
+## Latest-Compatible-First Rule
+
+- Start from the latest stable compatible dependency version, not an outdated tutorial version.
+- If the framework has an official scaffolder or setup command that produces current defaults, prefer that path over manually assembling stale `package.json` entries one by one.
+- Only step down to an older dependency version after documenting the exact compatibility, runtime, platform, or ecosystem reason.
+- Treat release notes, official docs, and framework migration guides as the primary source of truth for dependency setup.
+
 ## The Dependency Decision Framework
 
 Before adding ANY dependency, answer these 5 questions:
@@ -21,7 +28,7 @@ const padded = str.padStart(10, '0');
 const flat = nested.flat(Infinity);
 ```
 
-**Dependency Defense:** If the user asks to install a new library, or if you feel the need to use one, evaluate it against the "stdlib-first" rule. If the functionality can be implemented safely in under 20 lines of code, write it yourself. If a dependency is strictly necessary, you MUST justify it by providing its bundle size, maintenance status, and why the standard library is insufficient.
+**Dependency Defense:** If the user asks to install a new library, or if you feel the need to use one, evaluate it against the "stdlib-first" rule. If the functionality can be implemented safely in under 20 lines of code, write it yourself. If a dependency is strictly necessary, you MUST justify it by providing its bundle size, maintenance status, why the standard library is insufficient, and why the chosen version is the latest stable compatible option.
 
 ### 2. Is It Maintained? (The Pulse Check)
 | Signal | 🟢 Healthy | 🔴 Dead |
@@ -94,19 +101,23 @@ Purpose: [what it does in 1 sentence]
 Stdlib Alternative: [why it's insufficient — or "none"]
 Bundle Size: [minified + gzipped]
 Maintenance: [last release date, maintainer count]
+Version Source: [official docs, release notes, or framework reference]
 Lock-in Risk: [low/medium/high — how many files would it touch]
 Exit Strategy: [how to remove it if needed]
+Fallback Reason: [only required when not using the latest stable compatible version]
 ```
 
 ---
 
 ## Dependency Update Strategy
 
-1. **Pin exact versions** in lockfiles (already default with package-lock.json, bun.lockb)
-2. **Review changelogs** before major updates — never blindly `npm update`
-3. **Update in isolation** — one dependency per PR, with tests passing
-4. **Security patches immediately** — don't wait for the sprint
-5. **Monthly audit** — run `npm audit` / `bun audit` and address findings
+1. **Start from latest stable compatible versions** — older versions need a written reason
+2. **Prefer official framework setup flows** when they yield newer, canonical dependency sets
+3. **Pin exact versions** in lockfiles (already default with package-lock.json, bun.lockb)
+4. **Review changelogs** before major updates — never blindly `npm update`
+5. **Update in isolation** — one dependency per PR, with tests passing
+6. **Security patches immediately** — don't wait for the sprint
+7. **Monthly audit** — run `npm audit` / `bun audit` and address findings
 
 ---
 

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

@@ -15,6 +15,8 @@ Mandatory behavior when triggered:
 - apply structural checks from `.agent-context/review-checklists/architecture-review.md`
 - score and review generated UI work against visual intent, interaction quality, and conversion clarity
 - reject template-only repetitive outputs and force a distinct layout direction
+- treat prior website memory or old-project visual carryover as invalid evidence unless the user explicitly requests continuity with that exact system
+- do not flatten ambitious visual or motion ideas by default; keep them when they are optimized, intentional, and accessible
 
 ## UI Consistency Guardrails (Mandatory)
 
@@ -23,6 +25,9 @@ Mandatory behavior when triggered:
 - Layout must avoid overlap, clipped text, and misaligned key actions across breakpoints.
 - Responsive quality requires layout mutation and task reprioritization across breakpoints. Shrinking the desktop layout is not enough.
 - Keep spacing and positioning token-driven so repeated outputs stay stable.
+- Distinctive visual direction is allowed. Originality is a quality signal when hierarchy, task clarity, and accessibility still hold.
+- Motion is allowed to be expressive. Judge it by clarity, reduced-motion safety, and rendering cost, not by how restrained it looks.
+- Prefer transform and opacity for rich motion. Treat layout-thrashing animation, uncontrolled autoplay, and heavy continuous effects as optimization problems to solve, not reasons to remove personality from the UI entirely.
 
 ## 1. File Structure (Feature-Driven Design)
 Organize your application by feature domain, not by file type.

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

@@ -1,5 +1,5 @@
 {
-  "generatedAt": "2026-04-21T11:40:14.071Z",
+  "generatedAt": "2026-04-21T16:44:50.356Z",
   "reportName": "memory-continuity-benchmark",
   "schemaVersion": "1.0.0",
   "passed": true,

package/.cursorrules

@@ -1,6 +1,6 @@
 # AGENTIC-SENIOR-CORE DYNAMIC GOVERNANCE RULESET
 
-Generated by Agentic-Senior-Core CLI v3.0.13
+Generated by Agentic-Senior-Core CLI v3.0.15
 Timestamp: 2026-04-18T00:00:00.000Z
 Selected profile: beginner
 Selected policy file: .agent-context/policies/llm-judge-threshold.json

package/.gemini/instructions.md

@@ -2,18 +2,19 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 5de5017263401012b3516c76e68be3cfdc5d1f09a2569d5943cfcd4105e0dde4
+Canonical Snapshot SHA256: 060b739f87a77375f261a13c3b2b295993ba67b4172420c4223ba1332d47b0a3
 
 Canonical policy source: [.instructions.md](../.instructions.md).
 
 ## Bootstrap Sequence
 
-1. Load [.instructions.md](../.instructions.md) first.
-2. Apply baseline rules from [.agent-context/rules/](../.agent-context/rules).
-3. Load request templates from [.agent-context/prompts/](../.agent-context/prompts).
-4. Apply review contracts from [.agent-context/review-checklists/](../.agent-context/review-checklists).
-5. Apply state awareness from [.agent-context/state/](../.agent-context/state) and policy thresholds from [.agent-context/policies/](../.agent-context/policies).
-6. Resolve stack and architecture choices dynamically from project context docs plus live evidence.
+1. Load [.instructions.md](../.instructions.md) first as the canonical baseline.
+2. If `.agent-instructions.md` exists, read it next as the compiled project-specific snapshot.
+3. Apply baseline rules from [.agent-context/rules/](../.agent-context/rules).
+4. Load request templates from [.agent-context/prompts/](../.agent-context/prompts).
+5. Apply review contracts from [.agent-context/review-checklists/](../.agent-context/review-checklists).
+6. Apply state awareness from [.agent-context/state/](../.agent-context/state) and policy thresholds from [.agent-context/policies/](../.agent-context/policies).
+7. Resolve stack and architecture choices dynamically from project context docs plus live evidence.
 
 ## Completion Gate
 

package/.github/copilot-instructions.md

@@ -2,18 +2,19 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 5de5017263401012b3516c76e68be3cfdc5d1f09a2569d5943cfcd4105e0dde4
+Canonical Snapshot SHA256: 060b739f87a77375f261a13c3b2b295993ba67b4172420c4223ba1332d47b0a3
 
 The canonical policy source for this repository is [.instructions.md](../.instructions.md).
 
 ## Required Load Order
 
-1. Read [.instructions.md](../.instructions.md) first.
-2. Read baseline rules in [.agent-context/rules/](../.agent-context/rules).
-3. Load request templates from [.agent-context/prompts/](../.agent-context/prompts).
-4. Apply review contracts from [.agent-context/review-checklists/](../.agent-context/review-checklists).
-5. Apply state awareness from [.agent-context/state/](../.agent-context/state) and thresholds from [.agent-context/policies/](../.agent-context/policies).
-6. Resolve stack and architecture choices dynamically from project context docs plus live evidence.
+1. Read [.instructions.md](../.instructions.md) first as the canonical baseline.
+2. If `.agent-instructions.md` exists, read it next as the compiled project-specific snapshot.
+3. Read baseline rules in [.agent-context/rules/](../.agent-context/rules).
+4. Load request templates from [.agent-context/prompts/](../.agent-context/prompts).
+5. Apply review contracts from [.agent-context/review-checklists/](../.agent-context/review-checklists).
+6. Apply state awareness from [.agent-context/state/](../.agent-context/state) and thresholds from [.agent-context/policies/](../.agent-context/policies).
+7. Resolve stack and architecture choices dynamically from project context docs plus live evidence.
 
 ## Completion Gate
 

package/.instructions.md

@@ -0,0 +1,339 @@
+# Agentic-Senior-Core: Unified AI Agent Instructions
+
+> **Bootstrap File** — This file is automatically loaded when your IDE initializes in this workspace.
+> It unifies all 9 knowledge layers into a single authoritative context.
+
+---
+
+## Your Role
+
+You are a **Senior Software Architect**. You enforce production-grade engineering standards at all times. You do not generate "good enough" code — you generate **enterprise-production code**.
+You use clear, plain language in formal artifacts and do not use emoji.
+
+---
+
+## Complete Knowledge Base (All 9 Layers)
+
+Before responding to ANY request, ensure you have loaded ALL of these layers:
+
+### Layer 1: Rules (15 Files) [REQUIRED]
+
+**Location**: `.agent-context/rules/`
+
+Universal engineering standards that OVERRIDE everything else:
+
+- `naming-conv.md` — No lazy names like `data`, `res`, `x`
+- `architecture.md` — Transport → Service → Repository separation
+- `security.md` — Validate ALL input, parameterize queries, no hardcoded secrets
+- `performance.md` — Evidence-based optimization, watch N+1 queries
+- `error-handling.md` — Never swallow errors, use typed error codes
+- `testing.md` — Test pyramid, behavior over implementation
+- `git-workflow.md` — Conventional Commits, atomic changes
+- `efficiency-vs-hype.md` — Latest-compatible, stable deps over trendy ones
+- `api-docs.md` — OpenAPI 3.1 mandatory
+- `microservices.md` — Monolith first, strangler fig pattern
+- `event-driven.md` — Event sourcing, CQRS, idempotency
+- `database-design.md` — 3NF default, safe migrations
+- `realtime.md` — WebSocket scaling, strict pub/sub
+- `frontend-architecture.md` — Smart/Dumb UI patterns
+- `docker-runtime.md` - Latest-docs-first Dockerfile and Compose generation
+
+**What to do**: Read `.agent-context/rules/` before generating code. Every line you write must comply. 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, prefer the latest stable compatible dependency set and official setup flow before falling back to older manual versions.
+
+---
+
+### Layer 2: Stack Strategy Signals (Dynamic)
+
+**Location**: dynamic stack intelligence from project context, repository evidence, and live research.
+
+Resolve the best-fit language and runtime strategy for the project.
+The table below is illustrative, not exhaustive. It is a reasoning aid, not a locked menu.
+Do not force the project into the nearest listed stack if repository evidence, delivery constraints, team fit, hosting realities, or newer ecosystem signals point somewhere else.
+When a better-fit stack is outside this table, prefer the better fit and explain the measurable trade-off clearly.
+
+Example strategy signals:
+
+| Stack Strategy       | Typical Trigger            | When                      |
+| -------------------- | -------------------------- | ------------------------- |
+| TypeScript / Node.js | JS ecosystem + rapid API   | JavaScript/Node projects  |
+| Python               | data + service velocity    | Python projects           |
+| Go                   | low-latency service target | Go services               |
+| Java / Kotlin        | enterprise JVM constraints | JVM projects              |
+| Rust                 | memory-safe performance    | Systems language projects |
+| C# / .NET            | Microsoft platform fit     | .NET projects             |
+| PHP                  | legacy/web compatibility   | PHP projects              |
+| Ruby on Rails        | product iteration speed    | Rails projects            |
+| Flutter              | single-codebase mobile     | Flutter mobile apps       |
+| React Native         | JS-native mobile delivery  | React Native mobile apps  |
+
+**What to do**: Infer the stack from requirements, repository evidence, and current constraints; enforce language-specific conventions dynamically. Prefer the stack that best matches the project now, not the stack that appears most often in examples.
+
+---
+
+### Layer 3: Architecture Playbooks (Dynamic)
+
+**Location**: dynamic architecture intelligence from repository context, docs, and runtime constraints.
+
+Reference architecture playbooks when scaffolding new systems.
+The table below lists common internal playbook patterns, but it is not exhaustive and it is not a hard whitelist.
+If the project needs a better architecture shape than the listed examples, adapt the playbook or synthesize a new one from repo evidence, domain constraints, and runtime realities.
+Do not contort the project to fit the closest existing label.
+
+Example playbook patterns:
+
+| Architecture Playbook    | Use Case                   |
+| ------------------------ | -------------------------- |
+| `api-nextjs`             | Next.js API projects       |
+| `nestjs-logic`           | NestJS modules             |
+| `fastapi-service`        | FastAPI services           |
+| `spring-boot-api`        | Spring Boot APIs           |
+| `go-service`             | Go HTTP services           |
+| `aspnet-api`             | ASP.NET Minimal APIs       |
+| `laravel-api`            | Laravel APIs               |
+| `graphql-grpc-api`       | GraphQL / gRPC definitions |
+| `ci-github-actions`      | GitHub Actions CI/CD       |
+| `ci-gitlab`              | GitLab CI/CD               |
+| `kubernetes-manifests`   | K8s deployments            |
+| `infrastructure-as-code` | IaC patterns               |
+| `observability`          | OpenTelemetry stack        |
+| `mobile-app`             | Mobile app structure       |
+
+**What to do**: When the user asks for a new project or module, choose or synthesize the best-fit playbook based on the real problem, then scaffold accordingly. Explain why that shape is better than the nearest generic default.
+
+---
+
+### Layer 4: Execution Contracts (Dynamic)
+
+**Location**: dynamic execution contracts from prompts, review checklists, and policy thresholds.
+
+Execution contracts replace static skill packs with mandatory behavior contracts:
+
+| Contract                    | Scope                                             | Source                                                                                                        | When Applied                    |
+| --------------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------- |
+| **Implementation contract** | Build/refactor flow and architecture guardrails   | `.agent-context/prompts/init-project.md`, `.agent-context/prompts/refactor.md`                                | Any coding request              |
+| **Design contract**         | UI intent, responsiveness, and design consistency | `.agent-context/prompts/bootstrap-design.md`, `.agent-context/rules/frontend-architecture.md`                 | Any UI or UX request            |
+| **Review contract**         | Defect/risk-focused quality review                | `.agent-context/review-checklists/pr-checklist.md`, `.agent-context/review-checklists/architecture-review.md` | Any review or PR-intent request |
+| **Release contract**        | Validation and release posture checks             | `.agent-context/policies/llm-judge-threshold.json`, `scripts/release-gate.mjs`                                | Any release or publish flow     |
+
+**What to do**: Resolve the active contract for the request, then enforce every mandatory check before declaring completion.
+
+---
+
+### Layer 5: Prompts (4 Request Templates)
+
+**Location**: `.agent-context/prompts/`
+
+Meta-prompts that provide complete workflows for common scenarios:
+
+| Prompt                | Triggers                                                                                      |
+| --------------------- | --------------------------------------------------------------------------------------------- |
+| `init-project.md`     | "create new project", "set up", "scaffold" → Auto-Architect mode                             |
+| `refactor.md`         | "refactor", "improve", "clean up", "fix" → Safety-first refactoring                          |
+| `review-code.md`      | "review", "audit", "check", "analyze" → Deep architectural review                            |
+| `bootstrap-design.md` | "ui", "ux", "layout", "screen", "tailwind", "frontend", "redesign" → UI Design Mode         |
+
+**What to do**: When user request matches a trigger, load the full prompt to understand the workflow.
+For UI-only requests, keep context isolated: load `bootstrap-design.md` and `frontend-architecture.md` first, and do not eagerly load unrelated backend-only rules such as `database-design.md`, `docker-runtime.md`, or `microservices.md` unless the request explicitly crosses those boundaries.
+
+---
+
+### Layer 6: Governance Modes (Dynamic)
+
+**Location**: dynamic governance context from state files, policies, and repository norms.
+
+Organization governance defaults. Resolve mode from repository signals:
+
+| Governance Mode | Default Stack Bias   | CI Mode                      | When                            |
+| --------------- | -------------------- | ---------------------------- | ------------------------------- |
+| **platform**    | Go                   | Strict (critical+high block) | Shared infrastructure teams     |
+| **regulated**   | TypeScript + Java    | Blocking (all severities)    | Financial/healthcare/compliance |
+| **startup**     | TypeScript + Next.js | Permissive (critical only)   | Speed-focused orgs              |
+
+**What to do**: Check `.agent-context/state/` and policy thresholds for governance mode signals, then apply matching defaults.
+
+---
+
+### Layer 7: State & Benchmarks
+
+**Location**: `.agent-context/state/`
+
+Codebase-specific state and guardrails:
+
+| File                        | Purpose                                   |
+| --------------------------- | ----------------------------------------- |
+| `architecture-map.md`       | Critical-path modules, change risk zones  |
+| `dependency-map.md`         | Allowed dependencies, anti-cycle guidance |
+| `benchmark-analysis.json`   | Performance baselines                     |
+| `benchmark-thresholds.json` | Performance gates                         |
+| `benchmark-watchlist.json`  | Monitored metrics                         |
+
+**What to do**: Before major modifications, read `architecture-map.md` to understand risk zones.
+
+---
+
+### Layer 8: Policies & Thresholds
+
+**Location**: `.agent-context/policies/`
+
+Governance enforcement rules:
+
+| File                       | Content                                    |
+| -------------------------- | ------------------------------------------ |
+| `llm-judge-threshold.json` | LLM quality gates, skill tier requirements |
+
+**What to do**: Check your AI model's tier (beginner/balanced/advanced/expert) before complex tasks. Refuse work outside your tier.
+
+---
+
+### Layer 9: Project Context (Optional)
+
+**Location**: `docs/`
+
+Project-specific documentation generated during initialization:
+
+| File                              | Purpose                                        |
+| --------------------------------- | ---------------------------------------------- |
+| `project-brief.md`                | Project name, description, goals, constraints  |
+| `architecture-decision-record.md` | Stack justification and architecture decisions |
+| `database-schema.md`              | Initial database schema plan                   |
+| `api-contract.md`                 | Endpoint plan and API design                   |
+| `flow-overview.md`                | Data and user flow diagrams                    |
+
+**What to do**: If `docs/project-brief.md` exists, read all docs before writing application code. These are living references that describe _what_ to build.
+
+---
+
+### MCP Servers
+
+**Location**: `mcp.json`
+
+Available external tools and services:
+
+| Server | Purpose                                    | Transport |
+| ------ | ------------------------------------------ | --------- |
+| `lint` | Code validation via `scripts/validate.mjs` | stdio     |
+| `test` | Test execution via `tests/**/*.test.mjs`   | stdio     |
+
+**What to do**: Invoke MCP servers when you need validation, linting, or test execution.
+
+---
+
+## Mandatory Triggers
+
+### 1. Auto-Architect (NEW PROJECT)
+
+**Trigger**: User says "create", "build", "new project", "scaffold"
+
+**Workflow**:
+
+1. Read `.agent-context/rules/` → governance
+2. Read `.agent-context/prompts/init-project.md` → full workflow
+3. Infer stack strategy + architecture playbook from requirements, docs, and live evidence
+4. Produce architecture plan + execution scope
+5. **WAIT for user approval** before generating code
+
+### 2. Refactor Mode (EXISTING CODE)
+
+**Trigger**: User says "refactor", "improve", "fix", "clean up"
+
+**Workflow**:
+
+1. Read `.agent-context/rules/` → what's violated?
+2. Read `.agent-context/prompts/refactor.md` → safety-first approach
+3. Apply relevant execution contract from prompts/checklists
+4. Propose plan BEFORE executing changes
+5. **WAIT for approval**
+
+### 3. Code Review Mode
+
+**Trigger**: User says "review", "audit", "check", "analyze"
+
+**Workflow**:
+
+1. Load `.agent-context/review-checklists/pr-checklist.md`
+2. Load `.agent-context/review-checklists/architecture-review.md`
+3. Execute review against ALL rules
+4. Generate structured report
+
+### 4. UI Design Mode
+
+**Trigger**: User says "ui", "ux", "layout", "screen", "tailwind", "frontend", or "redesign"
+
+**Workflow**:
+
+1. Read `.agent-context/prompts/bootstrap-design.md` → dynamic design contract workflow
+2. Read `.agent-context/rules/frontend-architecture.md` → UI structure and consistency guardrails
+3. Read UI-relevant repository evidence from `.agent-context/state/onboarding-report.json`, current UI code, and `docs/*`
+4. Generate or refine `docs/DESIGN.md` plus `docs/design-intent.json` before UI implementation
+5. Keep context isolated: do not eagerly load backend-only rules such as `.agent-context/rules/database-design.md`, `.agent-context/rules/docker-runtime.md`, or `.agent-context/rules/microservices.md` unless the task explicitly touches those boundaries
+
+---
+
+## The Reasoning Chain (MANDATORY)
+
+Every time you reject, suggest a change, or enforce a rule:
+
+```
+REASONING CHAIN
+Problem: [WHY the current approach is dangerous/unprofessional]
+Solution: [The production-grade alternative]
+Why Better: [WHY this is professional — teach the human]
+```
+
+---
+
+## Definition of Done
+
+**NEVER claim "done"** without:
+
+1. All relevant rules from `.agent-context/rules/` applied
+2. Code reviewed against `.agent-context/review-checklists/pr-checklist.md` and `.agent-context/review-checklists/architecture-review.md`
+3. Universal SOP hard gates satisfied (`docs/architecture-decision-record.md`, and `docs/DESIGN.md` plus `docs/design-intent.json` for UI scope)
+4. MCP validation passed (`npm run validate`)
+
+---
+
+## Knowledge Inventory Checklist
+
+**AUDIT**: Verify all 9 layers are accessible:
+
+- [ ] Layer 1: Rules (14 files) — Governance
+- [ ] Layer 2: Stack Strategy Signals (dynamic) — Language conventions
+- [ ] Layer 3: Architecture Playbooks (dynamic) — Scaffolding
+- [ ] Layer 4: Execution Contracts (dynamic) — Mandatory behavior contracts
+- [ ] Layer 5: Prompts (4 templates) — Request workflows
+- [ ] Layer 6: Governance Modes (dynamic) — Org governance
+- [ ] Layer 7: State (maps, benchmarks) — Codebase state
+- [ ] Layer 8: Policies (thresholds) — Quality gates
+- [ ] Layer 9: Project Context (docs/) — Project-specific architecture and design
+
+**If any layer is unreachable**, report it to maintain context integrity.
+
+---
+
+## How Injection Works
+
+This file (`.instructions.md`) is the **canonical baseline** that ties everything together:
+
+1. **A thin adapter or IDE entrypoint resolves to this file** as the canonical source
+2. **If `.agent-instructions.md` exists, read it next** as the compiled project-specific snapshot
+3. **You read the layer index** to understand what is available
+4. **When a trigger matches**, you navigate to the specific layer files
+5. **You load domain-specific knowledge** as needed
+6. **You apply all mandatory checks** before shipping
+
+**Result**: 100% context visibility. No gaps. No missed governance.
+
+---
+
+## Pro Tips
+
+- **Before code**: Scan `.agent-context/rules/` + active execution contracts
+- **Before PR**: Run `.agent-context/review-checklists/pr-checklist.md`
+- **Before deploy**: Check `.agent-context/policies/llm-judge-threshold.json`
+- **Before major refactor**: Read `.agent-context/state/architecture-map.md` (risk zones)
+- **Stuck on naming**: Load `.agent-context/rules/naming-conv.md` (REQUIRED reading)
+
+---
+
+**Start here. If `.agent-instructions.md` exists, read it next. Otherwise continue directly into the layers.**

package/.windsurfrules

@@ -1,6 +1,6 @@
 # AGENTIC-SENIOR-CORE DYNAMIC GOVERNANCE RULESET
 
-Generated by Agentic-Senior-Core CLI v3.0.13
+Generated by Agentic-Senior-Core CLI v3.0.15
 Timestamp: 2026-04-18T00:00:00.000Z
 Selected profile: beginner
 Selected policy file: .agent-context/policies/llm-judge-threshold.json

package/AGENTS.md

@@ -2,20 +2,21 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 5de5017263401012b3516c76e68be3cfdc5d1f09a2569d5943cfcd4105e0dde4
+Canonical Snapshot SHA256: 060b739f87a77375f261a13c3b2b295993ba67b4172420c4223ba1332d47b0a3
 
 This file is an adapter entrypoint for agent discovery.
 The canonical policy source is [.instructions.md](.instructions.md).
 
 ## Mandatory Bootstrap Chain
 
-1. Load [.instructions.md](.instructions.md) first as the single source of truth.
-2. Read baseline governance from [.agent-context/rules/](.agent-context/rules).
-3. Apply request templates from [.agent-context/prompts/](.agent-context/prompts).
-4. Enforce review contracts from [.agent-context/review-checklists/](.agent-context/review-checklists).
-5. Read change-risk maps and continuity state from [.agent-context/state/](.agent-context/state).
-6. Enforce policy thresholds from [.agent-context/policies/](.agent-context/policies).
-7. Use dynamic stack and architecture reasoning from project context docs and live research signals.
+1. Load [.instructions.md](.instructions.md) first as the canonical baseline.
+2. If `.agent-instructions.md` exists, read it next as the compiled project-specific snapshot.
+3. Read baseline governance from [.agent-context/rules/](.agent-context/rules).
+4. Apply request templates from [.agent-context/prompts/](.agent-context/prompts).
+5. Enforce review contracts from [.agent-context/review-checklists/](.agent-context/review-checklists).
+6. Read change-risk maps and continuity state from [.agent-context/state/](.agent-context/state).
+7. Enforce policy thresholds from [.agent-context/policies/](.agent-context/policies).
+8. Use dynamic stack and architecture reasoning from project context docs and live research signals.
 
 ## Trigger Rules
 

package/lib/cli/commands/init.mjs

@@ -836,6 +836,7 @@ export async function runInitCommand(targetDirectoryArgument, initOptions = {})
         key: selectedProjectScopeKey,
         label: selectedProjectScopeLabel,
       },
+      projectTopology: discoveryAnswers?.architectureStyle || null,
       selectedStackFileName: selectedResolvedStackFileName,
       selectedAdditionalStackFileNames,
       selectedBlueprintFileName: selectedResolvedBlueprintFileName,
@@ -879,6 +880,9 @@ export async function runInitCommand(targetDirectoryArgument, initOptions = {})
     }
     if (!projectDetection.hasExistingProjectFiles) {
       console.log(`- Project domain: ${selectedProjectScopeLabel}`);
+      if (discoveryAnswers?.architectureStyle) {
+        console.log(`- Project topology: ${discoveryAnswers.architectureStyle}`);
+      }
     }
     console.log(`- Stack: ${toTitleCase(selectedResolvedStackFileName)}`);
     if (selectedAdditionalStackFileNames.length > 0) {
@@ -892,7 +896,7 @@ export async function runInitCommand(targetDirectoryArgument, initOptions = {})
     console.log(`- CI/CD quality checks (guardrails): ${includeCiGuardrails ? 'enabled' : 'disabled'}`);
     console.log(`- Blocking severities: ${formatBlockingSeverities(selectedProfile.blockingSeverities)}`);
     console.log(`- Setup time: ${formatDuration(setupDurationMs)}`);
-    console.log('- Generated files: .agent-instructions.md, .cursorrules, .windsurfrules, .clauderc, and .agent-context/state/onboarding-report.json');
+    console.log('- Generated files: .instructions.md, .agent-instructions.md, compiled adapters, and .agent-context/state/onboarding-report.json');
     if (scaffoldingResult?.bootstrapMode === 'ai-synthesis') {
       console.log(`- Bootstrap prompts: ${(scaffoldingResult.generatedPromptFileNames || []).length} files generated in .agent-context/prompts/`);
       if ((scaffoldingResult.materializedFileNames || []).length > 0) {

package/lib/cli/commands/upgrade.mjs

@@ -33,6 +33,7 @@ import {
 } from '../detector.mjs';
 import {
   buildCompiledRulesContent,
+  compileDynamicContext,
   writeSelectedPolicy,
   writeOnboardingReport,
   loadOnboardingReportIfExists,
@@ -408,8 +409,15 @@ export async function runUpgradeCommand(targetDirectoryArgument, upgradeOptions
         supplementalCreatedFileNames.push('docs/design-intent.json');
       }
 
-      await fs.writeFile(currentRulesPath, plannedRulesContent, 'utf8');
-      await fs.writeFile(path.join(resolvedTargetDirectoryPath, '.windsurfrules'), plannedRulesContent, 'utf8');
+      await compileDynamicContext({
+        targetDirectoryPath: resolvedTargetDirectoryPath,
+        selectedProfileName,
+        selectedStackFileName,
+        selectedAdditionalStackFileNames,
+        selectedBlueprintFileName,
+        selectedAdditionalBlueprintFileNames,
+        includeCiGuardrails,
+      });
       await writeSelectedPolicy(resolvedTargetDirectoryPath, selectedProfileName);
 
       const setupDurationMs = Date.now() - setupStartedAt;
@@ -452,7 +460,7 @@ export async function runUpgradeCommand(targetDirectoryArgument, upgradeOptions
         supplementalCreatedFileNames.forEach((fileName) => console.log(`  [NEW]     ${fileName} (seed)`));
       }
 
-      console.log('\nRefreshed files: .cursorrules, .windsurfrules, .agent-context/state/onboarding-report.json');
+      console.log('\nRefreshed files: .instructions.md, .agent-instructions.md, compiled adapters, and .agent-context/state/onboarding-report.json');
     } catch (error) {
       console.error('\n[FATAL] An error occurred during upgrade. Attempting automatic rollback...');
       try {

package/lib/cli/compiler.mjs

@@ -38,6 +38,7 @@ export async function writeOnboardingReport({
   selectedProfilePack,
   selectedPreset,
   projectScope = null,
+  projectTopology = null,
   selectedStackFileName,
   selectedAdditionalStackFileNames = [],
   selectedBlueprintFileName,
@@ -73,6 +74,7 @@ export async function writeOnboardingReport({
       : null,
     selectedPreset,
     projectScope,
+    projectTopology,
     selectedStack: selectedStackFileName,
     selectedAdditionalStacks: selectedAdditionalStackFileNames,
     selectedBlueprint: selectedBlueprintFileName,
@@ -188,8 +190,8 @@ export async function buildCompiledRulesContent({
       `6. .agent-context/policies/${POLICY_FILE_NAME}`,
       '7. docs/ project context (or bootstrap prompts when docs are not materialized)',
       '',
-      'Primary entrypoint: .agent-instructions.md',
-      'Adapter entrypoints: .cursorrules, .windsurfrules, .clauderc, .gemini/instructions.md, .github/copilot-instructions.md',
+      'Project-specific compiled snapshot: .agent-instructions.md',
+      'Compiled adapter entrypoints: .cursorrules, .windsurfrules, .clauderc, .gemini/instructions.md, .github/copilot-instructions.md',
       'Canonical baseline: .instructions.md',
     ].join('\n')
   );

package/lib/cli/project-scaffolder.mjs

@@ -55,6 +55,11 @@ const DOCKER_STRATEGY_CHOICES = [
   'Docker for both development and production',
 ];
 
+const ARCHITECTURE_STYLE_CHOICES = [
+  'Monolith',
+  'Microservice / distributed system',
+];
+
 function parseBooleanLikeValue(rawValue) {
   const normalizedValue = String(rawValue || '').trim().toLowerCase();
   if (['true', 'yes', 'y', '1'].includes(normalizedValue)) {
@@ -111,6 +116,34 @@ function resolveDockerStrategy({ dockerStrategy, useDocker, useDockerDevelopment
   return DOCKER_STRATEGY_CHOICES[0];
 }
 
+function resolveArchitectureStyle(rawArchitectureStyle) {
+  const normalizedArchitectureStyle = String(rawArchitectureStyle || '').trim().toLowerCase();
+
+  if (!normalizedArchitectureStyle) {
+    return ARCHITECTURE_STYLE_CHOICES[0];
+  }
+
+  if (normalizedArchitectureStyle === 'monolith' || normalizedArchitectureStyle === 'modular monolith') {
+    return ARCHITECTURE_STYLE_CHOICES[0];
+  }
+
+  if (
+    normalizedArchitectureStyle === 'microservice'
+    || normalizedArchitectureStyle === 'microservices'
+    || normalizedArchitectureStyle === 'distributed'
+    || normalizedArchitectureStyle === 'distributed system'
+    || normalizedArchitectureStyle === 'microservice / distributed system'
+  ) {
+    return ARCHITECTURE_STYLE_CHOICES[1];
+  }
+
+  const directMatch = ARCHITECTURE_STYLE_CHOICES.find(
+    (architectureStyleChoice) => architectureStyleChoice.toLowerCase() === normalizedArchitectureStyle
+  );
+
+  return directMatch || ARCHITECTURE_STYLE_CHOICES[0];
+}
+
 async function askFeatureList(userInterface) {
   console.log('\nList your key features (one per line, press Enter to finish):');
 
@@ -175,6 +208,12 @@ export async function runProjectDiscovery(userInterface, options = {}) {
     projectDescription = defaultProjectDescription || `A ${projectName} project.`;
   }
 
+  const architectureStyle = await askChoice(
+    'Project topology:',
+    ARCHITECTURE_STYLE_CHOICES,
+    userInterface
+  );
+
   const includeCiGuardrails = shouldAskForCiGuardrails
     ? await askYesNo(
       'Enable CI/CD quality checks (guardrails) and the LLM Judge policy?',
@@ -227,6 +266,7 @@ export async function runProjectDiscovery(userInterface, options = {}) {
   return {
     projectName,
     projectDescription,
+    architectureStyle,
     includeCiGuardrails,
     primaryDomain,
     databaseChoice,
@@ -349,8 +389,8 @@ function inferDesignKeywords(discoveryAnswers) {
         'Keep decision-critical information prominent while secondary merchandising stays quiet.',
         'Let imagery and spacing create premium perception before decorative effects do.',
       ],
-      motionPurpose: 'Use restrained motion to reinforce buying confidence, product continuity, and feedback. Motion should feel premium, not promotional.',
-      motionChoreography: 'Favor short hover/focus transitions, sheet choreography, and product-media continuity. Avoid looping hero motion, autoplay spectacle, and parallax-heavy scenes.',
+      motionPurpose: 'Use motion to reinforce buying confidence, product continuity, and premium delight. It may be theatrical at key moments if it stays fast, legible, and supportive of decision-making.',
+      motionChoreography: 'Favor fast hover and focus feedback, confident sheet choreography, product-media continuity, and one or two signature reveal moments. Avoid autoplay spectacle that distracts from purchase decisions.',
       motionDurations: {
         desktop: 180,
         mobile: 240,
@@ -382,8 +422,8 @@ function inferDesignKeywords(discoveryAnswers) {
         'Use visual weight to separate signal from operational noise.',
         'Reserve strong accents for alerts, decisions, and state transitions only.',
       ],
-      motionPurpose: 'Use motion as operational feedback and state continuity, never as ambient decoration that competes with dense information.',
-      motionChoreography: 'Prefer fast transitions for filters, drawers, status reveals, and row expansion. Avoid floaty choreography and ornamental motion that slows scanning.',
+      motionPurpose: 'Use motion as operational feedback and state continuity, while still allowing decisive state transitions that make dense workflows feel alive and controlled.',
+      motionChoreography: 'Prefer fast transitions for filters, drawers, status reveals, and row expansion, but allow strong confirmation moments when they improve confidence and scan clarity.',
       motionDurations: {
         desktop: 160,
         mobile: 220,
@@ -415,8 +455,8 @@ function inferDesignKeywords(discoveryAnswers) {
         'Use code-adjacent rhythm and hierarchy to build trust with technical users.',
         'Keep complexity legible through spacing, grouping, and explicit interaction states.',
       ],
-      motionPurpose: 'Use motion to clarify causality, reveal system state, and preserve context during multi-pane technical workflows.',
-      motionChoreography: 'Prefer subtle panel transitions, command feedback, and disclosure motion. Avoid ornamental sweeps that make technical work feel imprecise.',
+      motionPurpose: 'Use motion to clarify causality, reveal system state, preserve context, and give technical workflows a sense of precision instead of dead stillness.',
+      motionChoreography: 'Prefer sharp panel transitions, command feedback, disclosure motion, and occasional signature transitions that feel exact rather than ornamental.',
       motionDurations: {
         desktop: 170,
         mobile: 230,
@@ -448,8 +488,8 @@ function inferDesignKeywords(discoveryAnswers) {
         'Use contrast and spacing to guide attention between creation, moderation, and discovery.',
         'Give key interaction moments personality without sacrificing clarity.',
       ],
-      motionPurpose: 'Use motion to support reading rhythm, reveal structure, and reward contribution moments without overwhelming long-form consumption.',
-      motionChoreography: 'Favor reveal choreography for section transitions, lightweight feedback on participation, and measured media behavior. Avoid constant background motion.',
+      motionPurpose: 'Use motion to support reading rhythm, reveal structure, and reward contribution moments with visible craft, not generic restraint.',
+      motionChoreography: 'Favor reveal choreography for section transitions, expressive but measured feedback on participation, and media behavior that feels alive without becoming noisy.',
       motionDurations: {
         desktop: 190,
         mobile: 250,
@@ -468,7 +508,7 @@ function inferDesignKeywords(discoveryAnswers) {
   }
 
   return {
-    designPhilosophy: 'Project-specific clarity with one authored tension.',
+    designPhilosophy: 'Project-specific clarity with one authored tension and one memorable visual bet.',
     brandAdjectives: ['clear', 'human', 'distinct'],
     antiAdjectives: ['generic', 'template-like', 'trend-chasing'],
     typographyScaleRatio: '1.200',
@@ -480,8 +520,8 @@ function inferDesignKeywords(discoveryAnswers) {
       'Use rhythm, hierarchy, and motion intentionally so the interface feels authored.',
       'Keep the system flexible enough to evolve with product scope without losing identity.',
     ],
-    motionPurpose: 'Allow motion when it improves continuity, feedback, or perceived craft. Avoid banning motion outright, but reject decorative movement with no product value.',
-    motionChoreography: 'Use short, purposeful transitions and keep heavier choreography rare, opt-in, and explainable in product terms.',
+    motionPurpose: 'Allow motion to create continuity, feedback, perceived craft, and memorability. Optimize bold choreography instead of defaulting to restraint. Reject only motion that harms comprehension, accessibility, or runtime performance.',
+    motionChoreography: 'Use fast purposeful transitions for most interactions, but allow a small number of signature transitions or reveal moments when they strengthen product identity and remain technically cheap.',
     motionDurations: {
       desktop: 180,
       mobile: 240,
@@ -580,7 +620,8 @@ function buildDesignIntentContractObject({
       'Major interface decisions must be explainable in product and user terms.',
       'Accessibility, responsiveness, and implementation realism are non-negotiable.',
       'Cross-viewport behavior must reorganize tasks and navigation, not just scale the desktop layout down.',
-      'Motion may add character and continuity when it improves the product experience, but it must stay purposeful, performant, and optional for reduced-motion users.',
+      'Motion may add character, memorability, and continuity when it improves the product experience, but it must stay purposeful, performant, and optional for reduced-motion users.',
+      'At least one surface, compositional move, typographic decision, or motion motif should be recognizable at a glance.',
     ],
     forbiddenPatterns: [
       'generic-saas-hero',
@@ -596,6 +637,8 @@ function buildDesignIntentContractObject({
       allowHexDerivatives: true,
       requireMotionRationale: true,
       requireStateMorphology: true,
+      requireSignatureMove: true,
+      rejectTemplateNeutralLayout: true,
     },
     requiredDesignSections: DESIGN_REQUIRED_SECTIONS,
     implementation: {
@@ -605,6 +648,7 @@ function buildDesignIntentContractObject({
       requireMachineReadableContract: true,
       requireViewportMutationRules: true,
       requirePurposefulMotionGuidelines: true,
+      requireRecognizableVisualBet: true,
       bootstrapPrompt: '.agent-context/prompts/bootstrap-design.md',
       autoLoadedRuleFiles: [
         '.agent-context/prompts/bootstrap-design.md',
@@ -819,10 +863,13 @@ function buildProjectContextBootstrapPrompt({
     '8. Separate confirmed facts from assumptions explicitly. When context is incomplete, add an `Assumptions to Validate` section and a `Next Validation Action` line.',
     '9. If user inputs conflict with repo evidence, call out the conflict and choose the safer interpretation instead of silently forcing a generic answer.',
     '10. Do not invent modules or architecture layers only to make the docs look complete.',
+    '11. Prefer the latest stable compatible framework and package versions. If an official framework setup flow yields newer, better-supported defaults than manual package assembly, prefer that path.',
+    '12. Treat project topology as a design constraint: if the project is a monolith, explain why that shape is sufficient; if it is a microservice or distributed system, explain the service boundary logic and why the split is justified.',
     '',
     '## Project Inputs',
     `- Project name: ${discoveryAnswers.projectName}`,
     `- Project description: ${discoveryAnswers.projectDescription}`,
+    `- Project topology: ${discoveryAnswers.architectureStyle || ARCHITECTURE_STYLE_CHOICES[0]}`,
     `- Primary domain: ${discoveryAnswers.primaryDomain}`,
     `- Database strategy: ${discoveryAnswers.databaseChoice}`,
     `- Auth strategy: ${discoveryAnswers.authStrategy}`,
@@ -924,13 +971,15 @@ function buildDesignBootstrapPrompt({
     '6. Reject interchangeable hero layouts, generic SaaS gradients, and trend-chasing decoration unless the project context explicitly justifies them.',
     '7. Encode color intent in perceptual terms first. Hex values may exist only as implementation derivatives.',
     '8. Responsive guidance must include layout mutation rules for mobile, tablet, and desktop. Shrinking the desktop layout is not enough.',
-    '9. Motion is allowed when it reinforces feedback, continuity, or hierarchy. Do not remove motion entirely, but reject decorative motion that harms clarity or performance.',
+    '9. Motion can be bold, cinematic, or highly expressive when it improves memorability, hierarchy, feedback, or product confidence. Optimize it instead of flattening it. Only reject motion when it harms clarity, accessibility, or runtime performance.',
     '10. Define component morphology across interaction states and viewports so cards, forms, nav, and feedback surfaces adapt coherently instead of only resizing.',
     '11. Keep UI-only requests context-isolated. Load frontend design rules first and do not eagerly load backend-only rules unless the task explicitly crosses those boundaries.',
+    '12. Make at least one memorable visual bet so the resulting system is recognizable and not template-neutral.',
     '',
     '## Project Inputs',
     `- Project name: ${discoveryAnswers.projectName}`,
     `- Product context: ${discoveryAnswers.projectDescription}`,
+    `- Project topology: ${discoveryAnswers.architectureStyle || ARCHITECTURE_STYLE_CHOICES[0]}`,
     `- Domain: ${discoveryAnswers.primaryDomain}`,
     `- Stack: ${toTitleCase(initContext.stackFileName)}`,
     `- Blueprint: ${toTitleCase(initContext.blueprintFileName)}`,
@@ -1144,6 +1193,7 @@ export async function loadProjectConfig(configFilePath) {
   return {
     projectName: configEntries.projectName || configEntries.name || '',
     projectDescription: configEntries.projectDescription || configEntries.description || '',
+    architectureStyle: resolveArchitectureStyle(configEntries.architectureStyle || configEntries.topology || configEntries.serviceTopology),
     includeCiGuardrails: parseBooleanLikeValue(configEntries.includeCiGuardrails) ?? parseBooleanLikeValue(configEntries.ci) ?? true,
     primaryDomain: configEntries.primaryDomain || configEntries.domain || 'API service',
     databaseChoice: configEntries.databaseChoice || configEntries.database || 'None (stateless service)',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ryuenn3123/agentic-senior-core",
-  "version": "3.0.13",
+  "version": "3.0.15",
   "type": "module",
   "description": "Force your AI Agent to code like a Staff Engineer, not a Junior.",
   "bin": {
@@ -10,6 +10,7 @@
     "bin/",
     "lib/",
     "scripts/",
+    ".instructions.md",
     ".agent-context/",
     ".agents/",
     ".github/",

package/scripts/sync-thin-adapters.mjs

@@ -38,13 +38,14 @@ The canonical policy source is [.instructions.md](.instructions.md).
 
 ## Mandatory Bootstrap Chain
 
-1. Load [.instructions.md](.instructions.md) first as the single source of truth.
-2. Read baseline governance from [.agent-context/rules/](.agent-context/rules).
-3. Apply request templates from [.agent-context/prompts/](.agent-context/prompts).
-4. Enforce review contracts from [.agent-context/review-checklists/](.agent-context/review-checklists).
-5. Read change-risk maps and continuity state from [.agent-context/state/](.agent-context/state).
-6. Enforce policy thresholds from [.agent-context/policies/](.agent-context/policies).
-7. Use dynamic stack and architecture reasoning from project context docs and live research signals.
+1. Load [.instructions.md](.instructions.md) first as the canonical baseline.
+2. If \`.agent-instructions.md\` exists, read it next as the compiled project-specific snapshot.
+3. Read baseline governance from [.agent-context/rules/](.agent-context/rules).
+4. Apply request templates from [.agent-context/prompts/](.agent-context/prompts).
+5. Enforce review contracts from [.agent-context/review-checklists/](.agent-context/review-checklists).
+6. Read change-risk maps and continuity state from [.agent-context/state/](.agent-context/state).
+7. Enforce policy thresholds from [.agent-context/policies/](.agent-context/policies).
+8. Use dynamic stack and architecture reasoning from project context docs and live research signals.
 
 ## Trigger Rules
 
@@ -67,12 +68,13 @@ The canonical policy source for this repository is [.instructions.md](../.instru
 
 ## Required Load Order
 
-1. Read [.instructions.md](../.instructions.md) first.
-2. Read baseline rules in [.agent-context/rules/](../.agent-context/rules).
-3. Load request templates from [.agent-context/prompts/](../.agent-context/prompts).
-4. Apply review contracts from [.agent-context/review-checklists/](../.agent-context/review-checklists).
-5. Apply state awareness from [.agent-context/state/](../.agent-context/state) and thresholds from [.agent-context/policies/](../.agent-context/policies).
-6. Resolve stack and architecture choices dynamically from project context docs plus live evidence.
+1. Read [.instructions.md](../.instructions.md) first as the canonical baseline.
+2. If \`.agent-instructions.md\` exists, read it next as the compiled project-specific snapshot.
+3. Read baseline rules in [.agent-context/rules/](../.agent-context/rules).
+4. Load request templates from [.agent-context/prompts/](../.agent-context/prompts).
+5. Apply review contracts from [.agent-context/review-checklists/](../.agent-context/review-checklists).
+6. Apply state awareness from [.agent-context/state/](../.agent-context/state) and thresholds from [.agent-context/policies/](../.agent-context/policies).
+7. Resolve stack and architecture choices dynamically from project context docs plus live evidence.
 
 ## Completion Gate
 
@@ -91,12 +93,13 @@ Canonical policy source: [.instructions.md](../.instructions.md).
 
 ## Bootstrap Sequence
 
-1. Load [.instructions.md](../.instructions.md) first.
-2. Apply baseline rules from [.agent-context/rules/](../.agent-context/rules).
-3. Load request templates from [.agent-context/prompts/](../.agent-context/prompts).
-4. Apply review contracts from [.agent-context/review-checklists/](../.agent-context/review-checklists).
-5. Apply state awareness from [.agent-context/state/](../.agent-context/state) and policy thresholds from [.agent-context/policies/](../.agent-context/policies).
-6. Resolve stack and architecture choices dynamically from project context docs plus live evidence.
+1. Load [.instructions.md](../.instructions.md) first as the canonical baseline.
+2. If \`.agent-instructions.md\` exists, read it next as the compiled project-specific snapshot.
+3. Apply baseline rules from [.agent-context/rules/](../.agent-context/rules).
+4. Load request templates from [.agent-context/prompts/](../.agent-context/prompts).
+5. Apply review contracts from [.agent-context/review-checklists/](../.agent-context/review-checklists).
+6. Apply state awareness from [.agent-context/state/](../.agent-context/state) and policy thresholds from [.agent-context/policies/](../.agent-context/policies).
+7. Resolve stack and architecture choices dynamically from project context docs plus live evidence.
 
 ## Completion Gate
 

package/scripts/validate.mjs

@@ -287,6 +287,8 @@ const REQUIRED_UI_DESIGN_AUTOMATION_SNIPPETS = [
       '`crossViewportAdaptation.mutationRules.mobile/tablet/desktop`',
       '`motionSystem`',
       '`componentMorphology`',
+      'Do not reuse a color palette, component skin, or motion signature from prior chats, memories, or unrelated projects',
+      'If no approved reference system exists, synthesize the design from zero using current product context, constraints, and content only.',
     ],
   },
   {
@@ -328,6 +330,58 @@ const REQUIRED_UI_DESIGN_AUTOMATION_SNIPPETS = [
     ],
   },
 ];
+const REQUIRED_DOCKER_RUNTIME_AUTOMATION_SNIPPETS = [
+  {
+    path: '.instructions.md',
+    snippets: [
+      'docker-runtime.md',
+      'For Docker or Compose work, load `docker-runtime.md` and verify the latest official Docker docs before authoring container assets.',
+    ],
+  },
+  {
+    path: '.agent-context/rules/docker-runtime.md',
+    snippets: [
+      'latest official Docker documentation first',
+      'Docker Compose Quickstart',
+      'Compose file reference',
+      'Dockerfile best practices',
+      'Prefer current `docker compose` workflows and `compose.yaml`.',
+      'Do not add the top-level Compose `version` field by default.',
+      'Prefer the latest stable compatible Docker base image',
+    ],
+  },
+  {
+    path: '.agent-context/prompts/init-project.md',
+    snippets: [
+      '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.',
+      '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.',
+    ],
+  },
+];
+const REQUIRED_DEPENDENCY_FRESHNESS_AUTOMATION_SNIPPETS = [
+  {
+    path: '.instructions.md',
+    snippets: [
+      'prefer the latest stable compatible dependency set and official setup flow',
+    ],
+  },
+  {
+    path: '.agent-context/rules/efficiency-vs-hype.md',
+    snippets: [
+      'Latest-Compatible-First Rule',
+      'latest stable compatible dependency version',
+      'official scaffolder or setup command',
+      'Only step down to an older dependency version after documenting',
+    ],
+  },
+  {
+    path: '.agent-context/prompts/init-project.md',
+    snippets: [
+      'latest stable compatible dependency set and official framework setup flow first',
+      'Prefer official framework setup commands or canonical starter flows',
+    ],
+  },
+];
 const FORBIDDEN_TEMPLATE_BOOTSTRAP_SNIPPETS = [
   {
     path: 'lib/cli/project-scaffolder.mjs',
@@ -778,6 +832,12 @@ async function validatePackageMetadata() {
   } else {
     pass('package.json has no unnecessary devDependencies');
   }
+
+  if (Array.isArray(packageJson.files) && packageJson.files.includes('.instructions.md')) {
+    pass('package.json publishes canonical .instructions.md');
+  } else {
+    fail('package.json must publish .instructions.md so init and upgrade can copy the canonical root instructions file');
+  }
 }
 
 async function validatePolicyFile() {
@@ -1141,6 +1201,50 @@ async function validateUiDesignAutomationCoverage() {
   }
 }
 
+async function validateDockerRuntimeAutomationCoverage() {
+  console.log('\nChecking Docker runtime automation coverage...');
+
+  for (const coverageRule of REQUIRED_DOCKER_RUNTIME_AUTOMATION_SNIPPETS) {
+    const absoluteCoveragePath = join(ROOT_DIR, coverageRule.path);
+
+    if (!(await fileExists(absoluteCoveragePath))) {
+      fail(`Missing Docker runtime automation source: ${coverageRule.path}`);
+      continue;
+    }
+
+    const coverageContent = await readTextFile(absoluteCoveragePath);
+    for (const requiredSnippet of coverageRule.snippets) {
+      if (coverageContent.includes(requiredSnippet)) {
+        pass(`${coverageRule.path} includes Docker runtime automation snippet: ${requiredSnippet}`);
+      } else {
+        fail(`${coverageRule.path} is missing Docker runtime automation snippet: ${requiredSnippet}`);
+      }
+    }
+  }
+}
+
+async function validateDependencyFreshnessAutomationCoverage() {
+  console.log('\nChecking dependency freshness automation coverage...');
+
+  for (const coverageRule of REQUIRED_DEPENDENCY_FRESHNESS_AUTOMATION_SNIPPETS) {
+    const absoluteCoveragePath = join(ROOT_DIR, coverageRule.path);
+
+    if (!(await fileExists(absoluteCoveragePath))) {
+      fail(`Missing dependency freshness automation source: ${coverageRule.path}`);
+      continue;
+    }
+
+    const coverageContent = await readTextFile(absoluteCoveragePath);
+    for (const requiredSnippet of coverageRule.snippets) {
+      if (coverageContent.includes(requiredSnippet)) {
+        pass(`${coverageRule.path} includes dependency freshness automation snippet: ${requiredSnippet}`);
+      } else {
+        fail(`${coverageRule.path} is missing dependency freshness automation snippet: ${requiredSnippet}`);
+      }
+    }
+  }
+}
+
 async function validateDeterministicBoundaryEnforcementCoverage() {
   console.log('\nChecking deterministic boundary enforcement coverage...');
 
@@ -1411,6 +1515,8 @@ async function main() {
   await validateTemplateFreeBootstrapCoverage();
   await validateUpgradeUiContractWarningCoverage();
   await validateUiDesignAutomationCoverage();
+  await validateDockerRuntimeAutomationCoverage();
+  await validateDependencyFreshnessAutomationCoverage();
   await validateDeterministicBoundaryEnforcementCoverage();
   await validateStackResearchSnapshotState();
   await validateMcpConfiguration();