@ryuenn3123/agentic-senior-core 3.0.19 → 3.0.20

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

@@ -1,178 +1,13 @@
-# Testing — Prove It Works, Don't Pray
+# Testing Boundary
 
-> "It works on my machine" is not a test strategy.
-> Untested code is broken code that hasn't been caught yet.
+Use the test runner and style already present in the repo. If no test setup exists, the LLM must recommend a current, lightweight, project-fit setup from official docs before adding one.
 
-## The Test Pyramid (Enforced)
+Test what can break:
+- business rules, validation, authorization, state transitions, and error paths
+- public APIs, UI flows, integration boundaries, and data contracts touched by the change
+- regressions around bugs being fixed
+- critical accessibility or responsive behavior when UI is in scope
 
-```
-        ╱  E2E   ╲           Few — Slow — Expensive — Fragile
-       ╱──────────╲          Test critical user journeys only
-      ╱ Integration ╲        Medium — Test module boundaries
-     ╱────────────────╲      Database, API contracts, service interactions
-    ╱    Unit Tests     ╲    Many — Fast — Cheap — Stable
-   ╱──────────────────────╲  Test business logic in isolation
-```
+Do not test framework internals, third-party library behavior, private implementation trivia, or snapshots that only freeze noise.
 
-### Ratios
-- **Unit tests:** 70% — fast, isolated, test business rules
-- **Integration tests:** 20% — test boundaries (DB, APIs, modules)
-- **E2E tests:** 10% — test critical user flows only
-
----
-
-## What to Test (And What Not To)
-
-### ✅ ALWAYS Test
-- Business logic and calculations
-- Input validation rules
-- Edge cases (empty arrays, null values, boundary numbers)
-- Error handling paths (what happens when things fail)
-- State transitions and workflows
-- Authorization rules
-
-### ❌ NEVER Test
-- Framework internals (don't test that Express routes work)
-- Simple getters/setters with no logic
-- Third-party library behavior
-- Private implementation details (test behavior, not structure)
-- Database migrations (verify schema, don't test the migration tool)
-
----
-
-## Test Naming Convention
-
-### Pattern: `should [expected behavior] when [condition]`
-
-```
-❌ BANNED:
-test('test1')
-test('it works')
-test('calculateDiscount')
-
-✅ REQUIRED:
-test('should apply 20% discount when order total exceeds $100')
-test('should throw ValidationError when email format is invalid')
-test('should return empty array when user has no orders')
-test('should deny access when user lacks admin role')
-```
-
-**Rule:** A reader must understand the expected behavior WITHOUT reading the test body.
-
----
-
-## Test Structure: AAA Pattern
-
-Every test follows **Arrange → Act → Assert**:
-
-```typescript
-test('should calculate shipping as free when order exceeds $50', () => {
-  // Arrange — Set up the scenario
-  const order = createOrder({ items: [{ price: 60, quantity: 1 }] });
-
-  // Act — Execute the behavior
-  const shippingCost = calculateShipping(order);
-
-  // Assert — Verify the outcome
-  expect(shippingCost).toBe(0);
-});
-```
-
-### Rules
-- **ONE assert concept per test** (multiple `expect` calls are fine if they test the same concept)
-- **No logic in tests** (no if/else, no loops, no try/catch)
-- **Tests must be independent** — no shared mutable state, no execution order dependency
-- **Tests must be deterministic** — same input = same result, every time
-
----
-
-## Mocking Rules
-
-### Mock at Boundaries, Not Everywhere
-
-```
-❌ OVER-MOCKING (testing implementation, not behavior):
-test('should call repository.save exactly once', () => {
-  await service.createUser(userData);
-  expect(repository.save).toHaveBeenCalledTimes(1);
-  // If you refactor to call save differently, the test breaks
-  // even though the behavior hasn't changed
-});
-
-✅ CORRECT (testing behavior):
-test('should persist user and return created user', () => {
-  const result = await service.createUser(userData);
-  expect(result.id).toBeDefined();
-  expect(result.email).toBe(userData.email);
-  // You can verify the user exists in the test DB if integration test
-});
-```
-
-### When to Mock
-- External APIs (payment gateways, email services)
-- Time-dependent operations (use fake timers)
-- Non-deterministic operations (random, UUID)
-
-### When NOT to Mock
-- Your own code in the same module ← test the real integration
-- Simple utility functions ← use the real thing
-- Database in integration tests ← use a test database
-
----
-
-## Test Data Standards
-
-### Use Factories, Not Copy-Pasted Objects
-
-```
-❌ BANNED:
-test('should calculate total', () => {
-  const order = {
-    id: '123',
-    userId: '456',
-    items: [{ productId: '789', price: 29.99, quantity: 2, name: 'Widget' }],
-    status: 'pending',
-    createdAt: new Date(),
-    updatedAt: new Date(),
-    // ... 15 more fields copied from another test
-  };
-});
-
-✅ REQUIRED:
-test('should calculate total', () => {
-  const order = createTestOrder({
-    items: [createTestItem({ price: 29.99, quantity: 2 })],
-  });
-  // Factory fills in all other fields with sensible defaults
-});
-```
-
-### Rules
-- Create factory functions for each domain entity
-- Factories provide sensible defaults — tests override only relevant fields
-- Never use production data in tests
-- Use descriptive, obviously-fake data (email: `test-user@example.com`, not `john@gmail.com`)
-
----
-
-## Coverage Expectations
-
-| Layer | Min Coverage | What to Focus On |
-|-------|-------------|------------------|
-| Domain / Business Logic | 90%+ | All branching, edge cases, error paths |
-| Application / Service | 80%+ | Orchestration flows, error handling |
-| Transport / Controller | 60%+ | Input validation, error responses |
-| Utilities | 90%+ | All functions and edge cases |
-
-**Rule:** Coverage is a floor, not a goal. 100% coverage with bad tests is worse than 80% coverage with good tests. Focus on testing **behavior and edge cases**, not hitting a number.
-
----
-
-## When to Skip Tests (Rare)
-
-You may skip tests ONLY for:
-- Prototype/spike code (must be labeled `// SPIKE: will be replaced`)
-- Pure UI layout (visual testing is better here — use Storybook/Chromatic)
-- Generated code (test the generator, not the output)
-
-Everything else gets tested. No excuses.
+Tests should describe behavior, keep setup readable, and mock only at real boundaries such as network, filesystem, clock, database, or external services.

package/.agent-context/state/benchmark-analysis.json

@@ -77,7 +77,7 @@
       "our_above_line": [
         "Unified design system → code → deployed component library workflow",
         "Anti-slop enforcer with measurable aesthetic rules",
-        "Automated accessibility audit with auto-remediation suggestions",
+        "Automated accessibility audit with required remediation actions",
         "Performance budgeting integrated from design phase",
         "Component API contract validation (props, variants, logic)"
       ]
@@ -225,7 +225,7 @@
       ],
       "our_above_line": [
         "Interactive CLI initialization with live-reload preview",
-        "Configuration validator & fix suggestions",
+        "Configuration validator and required fix actions",
         "Skill selector CLI with auto-detection",
         "Automated upgrade CLI with dry-run & rollback",
         "Plugin ecosystem for skill extensions"
@@ -314,7 +314,7 @@
       ],
       "our_above_line": [
         "AI-assisted code review with benchmark comparison (detect regressions vs 3 repos)",
-        "Automated security vulnerability scanner + remediation suggestions",
+        "Automated security vulnerability scanner plus required remediation actions",
         "Performance regression gate (before/after benchmarks, SLO enforcement)",
         "Accessibility auto-audit + remediation",
         "Dependency audit with license compliance checking"

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

@@ -1,5 +1,5 @@
 {
-  "generatedAt": "2026-04-23T10:22:34.642Z",
+  "generatedAt": "2026-04-24T09:57:54.287Z",
   "reportName": "memory-continuity-benchmark",
   "schemaVersion": "1.0.0",
   "passed": true,

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

@@ -1,25 +1,43 @@
 {
-  "cliVersion": "2.5.16",
-  "generatedAt": "2026-04-18T00:00:00.000Z",
+  "cliVersion": "3.0.19",
+  "generatedAt": "2026-04-24T06:02:48.306Z",
   "operationMode": "upgrade",
   "selectedProfile": "beginner",
-  "selectedStack": "typescript.md",
+  "projectScope": null,
+  "projectTopology": null,
+  "runtimeDecision": {
+    "mode": "agent-decision-required",
+    "explicitStack": null,
+    "detectedStackEvidence": "typescript.md",
+    "detectedAdditionalStackEvidence": []
+  },
+  "architectureDecision": {
+    "mode": "agent-decision-required",
+    "explicitBlueprint": null,
+    "detectedBlueprintEvidence": null
+  },
+  "selectedStack": null,
   "selectedAdditionalStacks": [],
-  "selectedBlueprint": "api-nextjs.md",
+  "selectedBlueprint": null,
   "selectedAdditionalBlueprints": [],
   "ruleLoadingPolicy": {
     "canonicalSource": ".instructions.md",
     "stackLoadingMode": "lazy",
     "loadedOnDemand": true,
-    "primaryStack": "typescript.md",
-    "additionalStacks": []
+    "primaryStack": null,
+    "additionalStacks": [],
+    "agentDecisionRequired": true
   },
   "ciGuardrailsEnabled": true,
-  "setupDurationMs": 106,
-  "selectedSkillDomains": [],
+  "setupDurationMs": 127,
+  "runtimeEnvironment": null,
+  "tokenOptimization": null,
+  "memoryContinuity": null,
   "autoDetection": {
-    "recommendedStack": "typescript.md",
-    "recommendedBlueprint": "api-nextjs.md",
+    "detectedStack": "typescript.md",
+    "detectedAdditionalStacks": [],
+    "detectedBlueprint": null,
+    "detectedAdditionalBlueprints": [],
     "confidenceLabel": "high",
     "confidenceScore": 0.94,
     "confidenceGap": 0.94,
@@ -37,6 +55,48 @@
     "evidence": [
       "package.json",
       "tsconfig.json"
-    ]
+    ],
+    "detectionTransparency": {
+      "declaredAt": "2026-04-24T06:02:48.218Z",
+      "declarationType": "existing-project",
+      "declarationShown": true,
+      "detectionSummary": "This folder looks like Typescript with high confidence based on package.json, tsconfig.json. Confidence gap: 0.94.",
+      "activeRulesSummary": {
+        "canonicalSource": ".instructions.md",
+        "compiledEntrypoints": [
+          ".cursorrules",
+          ".windsurfrules"
+        ],
+        "stackLoadingMode": "lazy",
+        "selectedProfile": "beginner",
+        "selectedProfileDisplayName": "Beginner",
+        "blockingSeverities": [
+          "critical"
+        ],
+        "ciGuardrailsEnabled": true
+      },
+      "majorConstraints": [
+        "Preserve existing project markers and avoid forced stack migration.",
+        "Use runtime markers as evidence only unless the user already recorded an explicit runtime constraint.",
+        "Upgrade keeps prior explicit onboarding constraints but does not create new stack or blueprint decisions."
+      ],
+      "quickConfirmation": {
+        "offered": false,
+        "response": "upgrade-auto",
+        "source": "upgrade-assistant"
+      },
+      "decision": {
+        "mode": "upgrade-auto",
+        "selectedStackFileName": "agent-decision-runtime.md",
+        "selectedBlueprintFileName": "agent-decision-architecture.md"
+      }
+    },
+    "uiScope": {
+      "isUiScopeLikely": false,
+      "signalReasons": [],
+      "workspaceUiEntries": [],
+      "frontendEvidenceMetrics": null,
+      "designEvidenceSummary": null
+    }
   }
 }

package/.agents/workflows/init-project.md

@@ -1,29 +1,12 @@
 ---
-description: Initialize a new project using Agentic-Senior-Core blueprints and engineering standards
+description: Initialize a project with repo-grounded guidance and required docs
 ---
 
-// turbo-all
-
 ## Workflow: Initialize Project
 
-1. Read all rule files from `.agent-context/rules/` to understand engineering standards.
-
-2. Resolve language-specific guidance from dynamic stack signals based on the project's goals and constraints.
-
-3. Resolve the chosen architecture playbook (e.g., `api-nextjs` or `nestjs-logic`).
-
-4. Scaffold the complete project structure following the blueprint exactly:
-   - Create all directories and files
-   - Set up strict `tsconfig.json` (using active TypeScript guidance)
-   - Create `.env.example` with placeholder values
-   - Set up Zod-validated environment config
-   - Set up error handling foundation (base error class + global handler)
-   - Set up structured logger (pino)
-   - Create a `/health` endpoint
-   - Initialize the ORM with initial schema
-
-5. Verify every file follows `rules/naming-conv.md` naming conventions.
-
-6. Verify the architecture follows `rules/architecture.md` layer separation.
-
-7. Run the PR checklist from `.agent-context/review-checklists/pr-checklist.md` as a final quality gate.
+1. Read `AGENTS.md`, then follow the canonical bootstrap chain only as far as the task requires.
+2. Use `.agent-context/prompts/init-project.md` as the canonical init prompt.
+3. For existing projects, inspect real project files before naming the product, describing the context, or recommending runtime/architecture choices.
+4. For fresh projects, keep questions minimal and ask the agent to recommend unresolved runtime, framework, library, and architecture choices from the brief plus live official docs.
+5. Ensure required docs exist before implementation: project brief, architecture decision, flow overview, API/public contract when relevant, data model when relevant, UI design contract when relevant, security assumptions, and testing strategy.
+6. Run `.agent-context/review-checklists/pr-checklist.md` before declaring the init complete.

package/.agents/workflows/refactor.md

@@ -1,29 +1,12 @@
 ---
-description: Refactor code or extract a module following architecture and naming rules
+description: Refactor code without changing behavior
 ---
 
 ## Workflow: Refactor Code
 
-1. Read `.agent-context/rules/architecture.md` to understand the required layer separation.
-
-2. Read `.agent-context/rules/naming-conv.md` to understand naming standards.
-
-3. Read `.agent-context/rules/error-handling.md` to understand error handling patterns.
-
-4. Resolve the active language profile from dynamic stack signals (e.g., TypeScript guidance).
-
-5. Analyze the target code for violations:
-   - Layer leaks (business logic in controllers, SQL in services)
-   - Naming violations (generic names, missing verb prefixes, missing boolean prefixes)
-   - Error handling issues (swallowed errors, generic Error types)
-   - Type safety issues (any types, unvalidated input)
-
-6. Apply refactoring while maintaining ALL existing functionality:
-   - Separate into proper layers if needed (controller/service/repository)
-   - Fix all naming violations
-   - Add Zod validation at boundaries if missing
-   - Replace generic errors with typed error classes
-
-7. For every change, provide a Reasoning Chain explaining what was wrong and why the new approach is better.
-
-8. Run `.agent-context/review-checklists/pr-checklist.md` as a final quality gate.
+1. Read `AGENTS.md`.
+2. Use `.agent-context/prompts/refactor.md` as the canonical refactor prompt.
+3. Inspect the target files and existing repo conventions before changing structure.
+4. Keep behavior stable unless the user explicitly approves a behavior change.
+5. Update docs and tests when contracts, public surfaces, or architecture boundaries change.
+6. Run `.agent-context/review-checklists/pr-checklist.md` before declaring done.

package/.agents/workflows/review-code.md

@@ -1,28 +1,11 @@
-description: Run a comprehensive code review using PR and architecture checklists
+---
+description: Review code with project contracts and risk-first findings
 ---
 
 ## Workflow: Review Code
 
-1. Read `.agent-context/review-checklists/pr-checklist.md` and apply every item against the current codebase.
-
-2. Read `.agent-context/review-checklists/architecture-review.md` and apply every item against the current codebase.
-
-3. For every violation found, provide a Reasoning Chain:
-   - State the exact file and line
-   - Reference the specific rule (file + section from `.agent-context/rules/`)
-   - Explain WHY it's a problem
-   - Provide the corrected code
-
-4. Output results in this format:
-
-```
-## PR REVIEW RESULTS
-- PASS or FAIL for each item
-- Reasoning Chain for each failure
-
-## ARCHITECTURE REVIEW RESULTS
-- Boundary violation summary and risk level for each finding
-- Specific remediation for each finding
-
-## VERDICT: PASS or FAIL
-```
+1. Read `AGENTS.md`.
+2. Use `.agent-context/prompts/review-code.md` as the canonical review prompt.
+3. Apply `.agent-context/review-checklists/pr-checklist.md`.
+4. Load architecture, frontend, security, testing, API, event, realtime, or Docker rules only when the changed scope needs them.
+5. Report findings first, ordered by severity, with file/line references and concrete fixes.

package/.cursorrules

@@ -1,7 +1,7 @@
 # AGENTIC-SENIOR-CORE DYNAMIC GOVERNANCE RULESET
 
-Generated by Agentic-Senior-Core CLI v3.0.19
-Timestamp: 2026-04-22T12:30:18.799Z
+Generated by Agentic-Senior-Core CLI v3.0.20
+Timestamp: 2026-04-24T06:02:48.303Z
 Selected policy file: .agent-context/policies/llm-judge-threshold.json
 
 ## GOVERNANCE PRECEDENCE
@@ -16,11 +16,11 @@ Selected policy file: .agent-context/policies/llm-judge-threshold.json
 - Scope policy: every override must include module scope, rationale, and expiry date.
 
 ## BOOTSTRAP CHAIN (MANDATORY)
-Load every layer before responding. Do not skip steps:
+Resolve the smallest relevant layer set before responding. Do not eagerly load unrelated layers:
 1. .agent-context/rules/
-2. Resolve architecture and stack signals from project context and live evidence.
+2. Resolve runtime and architecture signals from project context, repo evidence, and live research.
 3. .agent-context/prompts/
-4. Dynamic architecture and stack signals (from project context + research evidence)
+4. Dynamic runtime and architecture decision 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)
@@ -28,8 +28,8 @@ Load every layer before responding. Do not skip steps:
 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:
+## LAYER 1: RULES (SCOPE-RESOLVED)
+Available rule files under .agent-context/rules/:
 1. .agent-context/rules/api-docs.md
 2. .agent-context/rules/architecture.md
 3. .agent-context/rules/database-design.md
@@ -46,16 +46,17 @@ Read every file under .agent-context/rules/ before implementation:
 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.
+Resolution policy: load only the rule files relevant to the current task and prioritize data safety and API contract integrity first, then writing polish.
+## LAYER 2: RUNTIME DECISION REQUIRED
+No runtime stack was selected by the user.
+For a fresh project, the first implementation step is to ask the AI agent to recommend a runtime/framework from the brief, constraints, and live official documentation.
+For an existing project, inspect repo markers and current files directly before editing. Detection evidence is not a migration instruction.
+Do not silently choose a stack from offline defaults.
 ## 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.
+Primary runtime constraint: unresolved until agent recommendation is approved
+Additional runtime guidance loads only when explicitly selected by the user or required by touched code.
+Load runtime-specific guidance only when task scope touches that runtime.
+Avoid eager loading unrelated runtime guidance 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
@@ -64,12 +65,12 @@ Load these prompt contracts only when their trigger matches the user request:
 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.
+- Keep UI-only requests context-isolated and do not eagerly load backend-only rules such as database-design.md, docker-runtime.md, microservices.md, git-workflow.md, or general implementation-theory rules 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 3: ARCHITECTURE DECISION REQUIRED
+No architecture blueprint was selected by the user.
+The AI agent must propose the architecture from the product brief, repo evidence, required docs, and live research before implementation.
+Do not map detected runtime markers into a blueprint automatically.
 ## 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)

package/.gemini/instructions.md

@@ -2,7 +2,7 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 3ddc44d1c3cad20aa06e31c45b5d7289b1b4cde46decb668b0347817222fb022
+Canonical Snapshot SHA256: e6984d32169e98e32c9e6b6d6209bb2613b63b22d1e66af63a70788be00c55d5
 
 Canonical policy source: [.instructions.md](../.instructions.md).
 
@@ -20,7 +20,7 @@ If your host stops at this file, follow this minimum floor:
 4. Load request templates from [.agent-context/prompts/](../.agent-context/prompts).
 5. Apply review contracts from [.agent-context/review-checklists/](../.agent-context/review-checklists).
 6. Apply state awareness from [.agent-context/state/](../.agent-context/state) and policy thresholds from [.agent-context/policies/](../.agent-context/policies).
-7. Resolve stack and architecture choices dynamically from project context docs plus live evidence.
+7. Resolve stack, structure, and dependency choices from project context docs plus live evidence.
 
 ## Completion Gate
 

package/.github/copilot-instructions.md

@@ -2,7 +2,7 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 3ddc44d1c3cad20aa06e31c45b5d7289b1b4cde46decb668b0347817222fb022
+Canonical Snapshot SHA256: e6984d32169e98e32c9e6b6d6209bb2613b63b22d1e66af63a70788be00c55d5
 
 The canonical policy source for this repository is [.instructions.md](../.instructions.md).
 
@@ -20,7 +20,7 @@ If your host stops at this file, follow this minimum floor:
 4. Load request templates from [.agent-context/prompts/](../.agent-context/prompts).
 5. Apply review contracts from [.agent-context/review-checklists/](../.agent-context/review-checklists).
 6. Apply state awareness from [.agent-context/state/](../.agent-context/state) and thresholds from [.agent-context/policies/](../.agent-context/policies).
-7. Resolve stack and architecture choices dynamically from project context docs plus live evidence.
+7. Resolve stack, structure, and dependency choices from project context docs plus live evidence.
 
 ## Completion Gate