@ryuenn3123/agentic-senior-core 3.0.14 → 3.0.16

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

@@ -11,20 +11,25 @@ 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.
 2. Read [frontend-architecture.md](../rules/frontend-architecture.md) and apply its UI consistency guardrails.
 3. Use repository evidence from [.agent-context/state/onboarding-report.json](../state/onboarding-report.json), existing UI code, product copy, route names, component names, and any existing `docs/*` project docs to infer architecture and product background.
-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.
-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.
-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.
+4. If `repoEvidence.designEvidenceSummary` exists, treat it as the machine-readable snapshot of the current visual system, token bypasses, and UI surface inventory before proposing a new direction.
+5. When analyzing an existing UI codebase, inspect low-cost evidence such as hardcoded color density, prop-drilling candidates, breakpoint chaos, CSS variable patterns, and component surface inventory before declaring the current design direction healthy.
+6. If [docs/DESIGN.md](../../docs/DESIGN.md) or `docs/design-intent.json` already exists, check for drift and improve them instead of rewriting blindly.
+7. If context is incomplete, write explicit assumptions and reversible design bets instead of defaulting to generic SaaS output.
+8. 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.
+9. 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.
+10. All references to docs or rules must be clickable markdown links.
+11. Responsive work must adapt layout, navigation, density, and task order across viewports. Shrinking desktop layouts is not enough.
+12. 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.
+13. 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.
+14. 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.
+15. 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.
+16. 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
@@ -33,12 +38,13 @@ Required `docs/DESIGN.md` sections:
 4. Color Science and Semantic Roles
 5. Typographic Engineering and Hierarchy
 6. Spacing, Layout Rhythm, and Density Strategy
-7. Responsive Strategy and Cross-Viewport Adaptation Matrix
-8. Interaction, Motion, and Feedback Rules
-9. Component Language, Morphology, and Shared Patterns
-10. Accessibility Non-Negotiables
-11. Anti-Patterns to Avoid
-12. Implementation Notes for Future UI Tasks
+7. Token Architecture and Alias Strategy
+8. Responsive Strategy and Cross-Viewport Adaptation Matrix
+9. Interaction, Motion, and Feedback Rules
+10. Component Language, Morphology, and Shared Patterns
+11. Accessibility Non-Negotiables
+12. Anti-Patterns to Avoid
+13. Implementation Notes for Future UI Tasks
 
 Required `docs/design-intent.json` fields:
 - `mode`
@@ -49,6 +55,7 @@ Required `docs/design-intent.json` fields:
 - `antiAdjectives`
 - `visualDirection`
 - `mathSystems`
+- `tokenSystem`
 - `colorTruth`
 - `crossViewportAdaptation`
 - `motionSystem`
@@ -58,14 +65,21 @@ Required `docs/design-intent.json` fields:
 - `validationHints`
 - `requiredDesignSections`
 - `implementation`
+- `repoEvidence` when onboarding or detector evidence exists
 
 Output:
 - Create or update both `docs/DESIGN.md` and `docs/design-intent.json`.
 - Keep both files synchronized: the markdown explains the why, the JSON captures the contract in machine-readable form.
+- `docs/design-intent.json` must define a real token system, not just loose style notes. Include primitive, semantic, and component layers plus aliasing rules and naming constraints.
 - `docs/design-intent.json` must include deterministic fields for `colorTruth.format`, `colorTruth.allowHexDerivatives`, and `crossViewportAdaptation.mutationRules.mobile/tablet/desktop`.
 - `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.
+- If onboarding or detector evidence exists, preserve it under `repoEvidence.designEvidenceSummary` instead of throwing away the machine-readable snapshot of the current UI system.
+- Token intent must stay structure-first: primitive tokens hold raw values, semantic tokens carry purpose, and component tokens consume semantic tokens instead of bypassing them with raw values.
 - 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/architecture.md

@@ -167,6 +167,19 @@ If these triggers don't exist, microservices are **premature complexity**.
 
 ## Project Structure: Feature-Based Grouping
 
+## Code Organization and File Size Discipline
+
+Keep modules small enough to understand in one focused read.
+
+- Prefer grouping by responsibility, not by convenience.
+- One folder should represent one clear area of responsibility.
+- Split discovery, validation, prompt building, persistence, and contract logic into separate modules when they grow.
+- Avoid mixed-purpose mega-files that combine constants, parsing, orchestration, validation, and I/O in one place.
+- Treat files above roughly 1000 lines as a refactor trigger, not a badge of completeness.
+- If a file grows past that threshold, extract stable submodules with clear names before adding more behavior.
+- Preserve one public entrypoint when it helps callers, but move the real implementation behind focused modules.
+- Tests may aggregate scenarios, but shared helpers and repeated setup should move into dedicated support files when the suite becomes hard to scan.
+
 ### ❌ BANNED: Technical Grouping
 ```
 src/

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-21T12:40:20.244Z",
+  "generatedAt": "2026-04-22T12:33:03.350Z",
   "reportName": "memory-continuity-benchmark",
   "schemaVersion": "1.0.0",
   "passed": true,

package/.agent-context/state/onboarding-report.json

@@ -3,7 +3,6 @@
   "generatedAt": "2026-04-18T00:00:00.000Z",
   "operationMode": "upgrade",
   "selectedProfile": "beginner",
-  "selectedProfilePack": null,
   "selectedStack": "typescript.md",
   "selectedAdditionalStacks": [],
   "selectedBlueprint": "api-nextjs.md",

package/.cursorrules

@@ -1,49 +1,86 @@
 # AGENTIC-SENIOR-CORE DYNAMIC GOVERNANCE RULESET
 
-Generated by Agentic-Senior-Core CLI v3.0.14
-Timestamp: 2026-04-18T00:00:00.000Z
-Selected profile: beginner
+Generated by Agentic-Senior-Core CLI v3.0.16
+Timestamp: 2026-04-22T12:30:18.799Z
 Selected policy file: .agent-context/policies/llm-judge-threshold.json
 
 ## GOVERNANCE PRECEDENCE
 1. Follow this compiled rulebook as the primary source.
 2. Resolve exceptions from .agent-override.md only when explicitly defined.
 3. Use architecture-map.md and dependency-map.md as change safety boundaries.
-4. Enforce pr-checklist.md and architecture-review.md before declaring completion.
+4. Enforce pr-checklist.md before declaring completion.
+
+## OVERRIDE PROTOCOL
+- Default: strict compliance with this file.
+- Exception path: .agent-override.md may explicitly allow narrow deviations.
+- Scope policy: every override must include module scope, rationale, and expiry date.
 
 ## BOOTSTRAP CHAIN (MANDATORY)
 Load every layer before responding. Do not skip steps:
 1. .agent-context/rules/
-2. Dynamic stack strategy signals from project context and live evidence.
-3. Dynamic architecture playbook signals from requirements and repository state.
-4. .agent-context/prompts/
-5. .agent-context/review-checklists/
-6. .agent-context/state/
-7. .agent-context/policies/llm-judge-threshold.json
-8. docs/ project context (or bootstrap prompts when docs are not materialized)
+2. Resolve architecture and stack signals from project context and live evidence.
+3. .agent-context/prompts/
+4. Dynamic architecture and stack signals (from project context + research evidence)
+5. .agent-context/state/
+6. .agent-context/policies/llm-judge-threshold.json
+7. docs/ project context (or bootstrap prompts when docs are not materialized)
 
-Primary entrypoint: .cursorrules
-Mirror entrypoint: .windsurfrules
+Project-specific compiled snapshot: .agent-instructions.md
+Compiled adapter entrypoints: .cursorrules, .windsurfrules, .clauderc, .gemini/instructions.md, .github/copilot-instructions.md
 Canonical baseline: .instructions.md
-
 ## LAYER 1: UNIVERSAL RULES (MANDATORY)
-Read every file under .agent-context/rules/ before implementation.
-Conflict resolution: prioritize data safety and API contract integrity first, then writing polish.
-
-## LAYER 2 POLICY: DYNAMIC STACK STRATEGY
-Resolve stack guidance lazily from project evidence. Do not depend on deleted static stack directories.
-
-## LAYER 3 POLICY: DYNAMIC ARCHITECTURE PLAYBOOKS
-Resolve architecture guidance lazily from project docs and task boundaries. Do not depend on deleted static blueprint directories.
-
-## STATE AWARENESS (MANDATORY)
-Load .agent-context/state/architecture-map.md and .agent-context/state/dependency-map.md before touching critical paths.
+Read every file under .agent-context/rules/ before implementation:
+1. .agent-context/rules/api-docs.md
+2. .agent-context/rules/architecture.md
+3. .agent-context/rules/database-design.md
+4. .agent-context/rules/docker-runtime.md
+5. .agent-context/rules/efficiency-vs-hype.md
+6. .agent-context/rules/error-handling.md
+7. .agent-context/rules/event-driven.md
+8. .agent-context/rules/frontend-architecture.md
+9. .agent-context/rules/git-workflow.md
+10. .agent-context/rules/microservices.md
+11. .agent-context/rules/naming-conv.md
+12. .agent-context/rules/performance.md
+13. .agent-context/rules/realtime.md
+14. .agent-context/rules/security.md
+15. .agent-context/rules/testing.md
 
+Conflict resolution: prioritize data safety and API contract integrity first, then writing polish.
+## LAYER 2: STACK PROFILE (typescript.md)
+Source: dynamic-research-signal (static stack profile file not required)
+Summary: Dynamic stack strategy signal for typescript.
+Load this stack profile to enforce language-specific conventions.
+## LAYER 2 POLICY: LAZY RULE LOADING
+Primary stack strategy is always loaded for this project: typescript.md (dynamic mode)
+Additional stack profiles load only when explicitly selected or detected.
+Load stack guidance only when task scope touches that stack.
+Avoid eager loading unrelated stack profiles to prevent instruction conflicts.
+## LAYER 5: EXECUTION PROMPTS AND UI TRIGGERS
+Load these prompt contracts only when their trigger matches the user request:
+1. .agent-context/prompts/init-project.md -> create, build, new project, scaffold
+2. .agent-context/prompts/refactor.md -> refactor, improve, clean up, fix
+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
+UI trigger policy:
+- Load .agent-context/prompts/bootstrap-design.md and .agent-context/rules/frontend-architecture.md first.
+- Keep UI-only requests context-isolated and do not eagerly load backend-only rules such as database-design.md, docker-runtime.md, or microservices.md unless the task explicitly crosses those boundaries.
+- For UI scope, materialize docs/DESIGN.md and docs/design-intent.json before implementing UI surfaces.
+## LAYER 3: BLUEPRINT PROFILE (api-nextjs.md)
+Source: dynamic-research-signal (static blueprint profile file not required)
+Summary: Dynamic architecture strategy signal for api nextjs.
+Load this blueprint when scaffolding or changing architecture boundaries.
+## LAYER 3B: CI/CD GUARDRAILS
+Load these CI blueprints when pipeline or release logic is touched:
+1. ci-github-actions.md (dynamic CI policy signal)
+2. ci-gitlab.md (dynamic CI policy signal)
+## LAYER 7: STATE AWARENESS (MANDATORY)
+Load these files before touching critical paths:
+1. .agent-context/state/architecture-map.md
+2. .agent-context/state/dependency-map.md
+Use these maps to prevent unsafe cross-module changes.
 ## REVIEW CHECKLISTS (MANDATORY)
 1. .agent-context/review-checklists/pr-checklist.md
 2. .agent-context/review-checklists/architecture-review.md
+Security and performance checks are consolidated inside these two checklist files.
 Do not claim done before checklist pass.
-
-## UNIVERSAL SOP HARD GATES
-- Stop coding if docs/architecture-decision-record.md (or docs/Architecture-Decision-Record.md) is missing.
-- For UI scope, stop coding if docs/DESIGN.md or docs/design-intent.json is missing.

package/.gemini/instructions.md

@@ -2,7 +2,7 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 85b816e37107188c2776f0ac144d46a11dfc895af5db2656b0d6c12d0dd59dbc
+Canonical Snapshot SHA256: 060b739f87a77375f261a13c3b2b295993ba67b4172420c4223ba1332d47b0a3
 
 Canonical policy source: [.instructions.md](../.instructions.md).
 

package/.github/copilot-instructions.md

@@ -2,7 +2,7 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 85b816e37107188c2776f0ac144d46a11dfc895af5db2656b0d6c12d0dd59dbc
+Canonical Snapshot SHA256: 060b739f87a77375f261a13c3b2b295993ba67b4172420c4223ba1332d47b0a3
 
 The canonical policy source for this repository is [.instructions.md](../.instructions.md).
 

package/.instructions.md

@@ -16,7 +16,7 @@ You use clear, plain language in formal artifacts and do not use emoji.
 
 Before responding to ANY request, ensure you have loaded ALL of these layers:
 
-### Layer 1: Rules (14 Files) [REQUIRED]
+### Layer 1: Rules (15 Files) [REQUIRED]
 
 **Location**: `.agent-context/rules/`
 
@@ -29,15 +29,16 @@ Universal engineering standards that OVERRIDE everything else:
 - `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` — Stable deps over trendy ones
+- `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.
+**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.
 
 ---
 

package/.windsurfrules

@@ -1,49 +1,86 @@
 # AGENTIC-SENIOR-CORE DYNAMIC GOVERNANCE RULESET
 
-Generated by Agentic-Senior-Core CLI v3.0.14
-Timestamp: 2026-04-18T00:00:00.000Z
-Selected profile: beginner
+Generated by Agentic-Senior-Core CLI v3.0.16
+Timestamp: 2026-04-22T12:30:18.799Z
 Selected policy file: .agent-context/policies/llm-judge-threshold.json
 
 ## GOVERNANCE PRECEDENCE
 1. Follow this compiled rulebook as the primary source.
 2. Resolve exceptions from .agent-override.md only when explicitly defined.
 3. Use architecture-map.md and dependency-map.md as change safety boundaries.
-4. Enforce pr-checklist.md and architecture-review.md before declaring completion.
+4. Enforce pr-checklist.md before declaring completion.
+
+## OVERRIDE PROTOCOL
+- Default: strict compliance with this file.
+- Exception path: .agent-override.md may explicitly allow narrow deviations.
+- Scope policy: every override must include module scope, rationale, and expiry date.
 
 ## BOOTSTRAP CHAIN (MANDATORY)
 Load every layer before responding. Do not skip steps:
 1. .agent-context/rules/
-2. Dynamic stack strategy signals from project context and live evidence.
-3. Dynamic architecture playbook signals from requirements and repository state.
-4. .agent-context/prompts/
-5. .agent-context/review-checklists/
-6. .agent-context/state/
-7. .agent-context/policies/llm-judge-threshold.json
-8. docs/ project context (or bootstrap prompts when docs are not materialized)
+2. Resolve architecture and stack signals from project context and live evidence.
+3. .agent-context/prompts/
+4. Dynamic architecture and stack signals (from project context + research evidence)
+5. .agent-context/state/
+6. .agent-context/policies/llm-judge-threshold.json
+7. docs/ project context (or bootstrap prompts when docs are not materialized)
 
-Primary entrypoint: .cursorrules
-Mirror entrypoint: .windsurfrules
+Project-specific compiled snapshot: .agent-instructions.md
+Compiled adapter entrypoints: .cursorrules, .windsurfrules, .clauderc, .gemini/instructions.md, .github/copilot-instructions.md
 Canonical baseline: .instructions.md
-
 ## LAYER 1: UNIVERSAL RULES (MANDATORY)
-Read every file under .agent-context/rules/ before implementation.
-Conflict resolution: prioritize data safety and API contract integrity first, then writing polish.
-
-## LAYER 2 POLICY: DYNAMIC STACK STRATEGY
-Resolve stack guidance lazily from project evidence. Do not depend on deleted static stack directories.
-
-## LAYER 3 POLICY: DYNAMIC ARCHITECTURE PLAYBOOKS
-Resolve architecture guidance lazily from project docs and task boundaries. Do not depend on deleted static blueprint directories.
-
-## STATE AWARENESS (MANDATORY)
-Load .agent-context/state/architecture-map.md and .agent-context/state/dependency-map.md before touching critical paths.
+Read every file under .agent-context/rules/ before implementation:
+1. .agent-context/rules/api-docs.md
+2. .agent-context/rules/architecture.md
+3. .agent-context/rules/database-design.md
+4. .agent-context/rules/docker-runtime.md
+5. .agent-context/rules/efficiency-vs-hype.md
+6. .agent-context/rules/error-handling.md
+7. .agent-context/rules/event-driven.md
+8. .agent-context/rules/frontend-architecture.md
+9. .agent-context/rules/git-workflow.md
+10. .agent-context/rules/microservices.md
+11. .agent-context/rules/naming-conv.md
+12. .agent-context/rules/performance.md
+13. .agent-context/rules/realtime.md
+14. .agent-context/rules/security.md
+15. .agent-context/rules/testing.md
 
+Conflict resolution: prioritize data safety and API contract integrity first, then writing polish.
+## LAYER 2: STACK PROFILE (typescript.md)
+Source: dynamic-research-signal (static stack profile file not required)
+Summary: Dynamic stack strategy signal for typescript.
+Load this stack profile to enforce language-specific conventions.
+## LAYER 2 POLICY: LAZY RULE LOADING
+Primary stack strategy is always loaded for this project: typescript.md (dynamic mode)
+Additional stack profiles load only when explicitly selected or detected.
+Load stack guidance only when task scope touches that stack.
+Avoid eager loading unrelated stack profiles to prevent instruction conflicts.
+## LAYER 5: EXECUTION PROMPTS AND UI TRIGGERS
+Load these prompt contracts only when their trigger matches the user request:
+1. .agent-context/prompts/init-project.md -> create, build, new project, scaffold
+2. .agent-context/prompts/refactor.md -> refactor, improve, clean up, fix
+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
+UI trigger policy:
+- Load .agent-context/prompts/bootstrap-design.md and .agent-context/rules/frontend-architecture.md first.
+- Keep UI-only requests context-isolated and do not eagerly load backend-only rules such as database-design.md, docker-runtime.md, or microservices.md unless the task explicitly crosses those boundaries.
+- For UI scope, materialize docs/DESIGN.md and docs/design-intent.json before implementing UI surfaces.
+## LAYER 3: BLUEPRINT PROFILE (api-nextjs.md)
+Source: dynamic-research-signal (static blueprint profile file not required)
+Summary: Dynamic architecture strategy signal for api nextjs.
+Load this blueprint when scaffolding or changing architecture boundaries.
+## LAYER 3B: CI/CD GUARDRAILS
+Load these CI blueprints when pipeline or release logic is touched:
+1. ci-github-actions.md (dynamic CI policy signal)
+2. ci-gitlab.md (dynamic CI policy signal)
+## LAYER 7: STATE AWARENESS (MANDATORY)
+Load these files before touching critical paths:
+1. .agent-context/state/architecture-map.md
+2. .agent-context/state/dependency-map.md
+Use these maps to prevent unsafe cross-module changes.
 ## REVIEW CHECKLISTS (MANDATORY)
 1. .agent-context/review-checklists/pr-checklist.md
 2. .agent-context/review-checklists/architecture-review.md
+Security and performance checks are consolidated inside these two checklist files.
 Do not claim done before checklist pass.
-
-## UNIVERSAL SOP HARD GATES
-- Stop coding if docs/architecture-decision-record.md (or docs/Architecture-Decision-Record.md) is missing.
-- For UI scope, stop coding if docs/DESIGN.md or docs/design-intent.json is missing.

package/AGENTS.md

@@ -2,7 +2,7 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 85b816e37107188c2776f0ac144d46a11dfc895af5db2656b0d6c12d0dd59dbc
+Canonical Snapshot SHA256: 060b739f87a77375f261a13c3b2b295993ba67b4172420c4223ba1332d47b0a3
 
 This file is an adapter entrypoint for agent discovery.
 The canonical policy source is [.instructions.md](.instructions.md).