@ryuenn3123/agentic-senior-core 3.0.14 → 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-21T12:40:20.244Z",
+  "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.14
+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,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,6 +1,6 @@
 # AGENTIC-SENIOR-CORE DYNAMIC GOVERNANCE RULESET
 
-Generated by Agentic-Senior-Core CLI v3.0.14
+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,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).

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) {

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,

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.14",
+  "version": "3.0.15",
   "type": "module",
   "description": "Force your AI Agent to code like a Staff Engineer, not a Junior.",
   "bin": {

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',
@@ -1147,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...');
 
@@ -1417,6 +1515,8 @@ async function main() {
   await validateTemplateFreeBootstrapCoverage();
   await validateUpgradeUiContractWarningCoverage();
   await validateUiDesignAutomationCoverage();
+  await validateDockerRuntimeAutomationCoverage();
+  await validateDependencyFreshnessAutomationCoverage();
   await validateDeterministicBoundaryEnforcementCoverage();
   await validateStackResearchSnapshotState();
   await validateMcpConfiguration();