@ryuenn3123/agentic-senior-core 3.0.19 → 3.0.21

package/.instructions.md

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

package/.windsurfrules

@@ -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.21
+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/AGENTS.md

@@ -2,7 +2,7 @@
 
 Adapter Mode: thin
 Adapter Source: .instructions.md
-Canonical Snapshot SHA256: 3ddc44d1c3cad20aa06e31c45b5d7289b1b4cde46decb668b0347817222fb022
+Canonical Snapshot SHA256: e6984d32169e98e32c9e6b6d6209bb2613b63b22d1e66af63a70788be00c55d5
 
 This file is an adapter entrypoint for agent discovery.
 The canonical policy source is [.instructions.md](.instructions.md).
@@ -16,7 +16,7 @@ If your host stops at this file instead of following the full chain, obey the Cr
 - For UI, UX, layout, screen, tailwind, frontend, or redesign requests: load [.agent-context/prompts/bootstrap-design.md](.agent-context/prompts/bootstrap-design.md) and [.agent-context/rules/frontend-architecture.md](.agent-context/rules/frontend-architecture.md) before editing code.
 - For UI scope: if `docs/DESIGN.md` or `docs/design-intent.json` is missing, materialize or refine them before implementing UI changes.
 - For refactor, improve, clean up, or fix requests: inspect the active rules and propose a plan before editing.
-- For new project or module requests: propose architecture before generating code.
+- For new project or module requests: clarify constraints, stack decisions, and required docs before generating code.
 - For ecosystem, framework, dependency, or Docker claims: perform live web research instead of relying on stale local heuristics.
 
 ## Mandatory Bootstrap Chain
@@ -28,11 +28,11 @@ If your host stops at this file instead of following the full chain, obey the Cr
 5. Enforce review contracts from [.agent-context/review-checklists/](.agent-context/review-checklists).
 6. Read change-risk maps and continuity state from [.agent-context/state/](.agent-context/state).
 7. Enforce policy thresholds from [.agent-context/policies/](.agent-context/policies).
-8. Use dynamic stack and architecture reasoning from project context docs and live research signals.
+8. Use dynamic stack, structure, and live research signals from project context docs.
 
 ## Trigger Rules
 
-- New project or module requests: propose architecture first and wait for approval.
+- New project or module requests: propose scope, constraints, and required docs first, then wait for approval.
 - Refactor or fix requests: propose plan first, then execute safely.
 - Completion: run [.agent-context/review-checklists/pr-checklist.md](.agent-context/review-checklists/pr-checklist.md) before declaring done.