@ryuenn3123/agentic-senior-core 3.0.15 → 3.0.16

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

@@ -17,18 +17,19 @@ 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 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 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.
+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
@@ -37,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`
@@ -53,6 +55,7 @@ Required `docs/design-intent.json` fields:
 - `antiAdjectives`
 - `visualDirection`
 - `mathSystems`
+- `tokenSystem`
 - `colorTruth`
 - `crossViewportAdaptation`
 - `motionSystem`
@@ -62,12 +65,16 @@ 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 optimize choreography instead of suppressing it by default.

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/state/memory-continuity-benchmark.json

@@ -1,5 +1,5 @@
 {
-  "generatedAt": "2026-04-21T16:44:50.356Z",
+  "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.15
-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/.windsurfrules

@@ -1,49 +1,86 @@
 # AGENTIC-SENIOR-CORE DYNAMIC GOVERNANCE RULESET
 
-Generated by Agentic-Senior-Core CLI v3.0.15
-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.