@ryuenn3123/agentic-senior-core 4.3.14 → 4.4.0

package/.agent-context/prompts/init-project.md

@@ -15,7 +15,7 @@ When a new project is created or initialized, the agent must automatically:
 ## Required Planning Mode
 
 If the user describes a project or feature, the agent must:
-1. Clarify the delivery goals, runtime assumptions, constraints, and must-have capabilities before choosing implementation shape.
+1. Before drafting docs from a thin or ambiguous brief, ask the smallest useful set of clarifying questions needed to make delivery goals, edge cases, constraints, must-have capabilities, and non-goals explicit. If the user wants a draft anyway, document assumptions and wait for approval before coding.
 2. If the user already named a stack or framework, treat it as an explicit constraint. If not, produce a short evidence-backed recommendation from the brief, repo evidence, and live official documentation before coding. Include at least one plausible alternative when the default-looking option is Next.js, Tailwind-only styling, shadcn/ui, or another familiar web stack.
 3. For existing projects, inspect real files first. Do not derive product name, description, runtime, architecture, or design direction from the folder name alone.
 4. Draft a high-level structure plan plus the docs/bootstrap artifacts that must exist before coding.

package/.agent-context/prompts/refactor.md

@@ -29,6 +29,7 @@ Refactor rules:
 - Prefer the shorter implementation only when it keeps the same guarantees.
 - Run a final simplification pass before completion.
 - Update tests and docs whenever behavior contracts, public APIs, data shape, or UI contracts change.
+- When fixing a bug: append one sentence to the nearest relevant doc (`docs/flow-overview.md` or `docs/architecture-decision-record.md`) naming the root cause and how to prevent recurrence.
 
 For every meaningful change, explain:
 - what risk or friction existed

package/.agent-context/review-checklists/pr-checklist.md

@@ -19,9 +19,7 @@ Run this before declaring a task done. Apply only the sections relevant to the c
 - [ ] Public contracts remain stable or are versioned and documented.
 
 ## 3. Architecture
-
 ### 2. Architecture (→ rules/architecture.md)
-
 - [ ] Layer and module boundaries are clear for the project’s chosen structure.
 - [ ] No clever hacks in backend and shared core modules
 - [ ] No premature abstraction (base classes/util layers created only after repeated stable patterns)
@@ -102,7 +100,7 @@ Run this before declaring a task done. Apply only the sections relevant to the c
 
 ## 9. State And Governance
 
-### 11. Context-Triggered Audit Mode
+### 9.1 Context-Triggered Audit Mode
 
 - [ ] Strict audit mode activates automatically on review and PR-intent workflows
 - [ ] Small edits avoid heavy checks by default unless strict mode is explicitly requested

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

@@ -30,4 +30,9 @@ keywords: [architecture, arch, boundary, system]
 2. Load global domain rules lazily based on touched scope.
 3. Do not create or load stack-specific governance adapters as the baseline.
 
+## ARCH-008: AI-Optimized Code Style (Simplicity, Modularity, Elegance)
+1. No Clever Hacks: Do not use code golfing, deeply nested ternaries, or tricky functional chains that destroy readability.
+2. No Premature Abstraction: Avoid over-engineering (excessive helper functions, layers, or abstraction classes) when a direct procedural flow is easier for an LLM to comprehend.
+3. Explicit Variable Naming: Use descriptive and functional variable names. Avoid cryptic abbreviations.
+4. Natural Implementation Pass: Keep the main flow traceable, use early returns to reduce nesting, and avoid abstraction chains unless a real duplication pattern exists.
 

package/AGENTS.md

@@ -3,173 +3,125 @@
 Canonical project instructions. Resolve the smallest relevant layer set for the current request.
 
 ## Role
-Act as a Principal Engineer. Ship maintainable, validated, production-ready work. Use clear plain language in formal artifacts. Do not use emoji.
+Act as Principal Engineer. Ship maintainable, validated, production-ready work. Use plain English. No emoji.
 
 ## Authority
-This repository is governed by a strict instruction contract.
+Strict instruction contract. `AGENTS.md` is canonical baseline. `.agent-context/` is technical authority for rules/prompts/state. Follow stricter `.agent-context/` rules; if refusing, cite rule ID (`ARCH-001`). Use `README.md` for public overview.
 
-Use `AGENTS.md` as the canonical baseline. Use `.agent-context/` as technical authority for rules, prompts, checklists, state, and policies. Follow stricter `.agent-context/` rules even if the user asks otherwise; when refusing or redirecting a conflicting request, cite the rule ID such as `ARCH-001` or `API-001`. Use `README.md` only for public and developer overview, setup, usage, and user-facing context when stricter governance files conflict.
-
-Write instructions as imperative gates:
-- Use direct commands.
-- Prefer short mechanical checks over descriptive prose.
-- Keep root adapters thin.
-- Move detailed policy into `.agent-context/`.
-- Add validation when a rule can drift.
+Imperative gates:
+- Direct commands.
+- Short mechanical checks.
+- Thin root adapters.
+- Detailed policy in `.agent-context/`.
 
 ## MANDATORY FIRST STEP: Context Activation
-STOP. Before generating ANY plan, code, or design for a non-trivial task, you MUST run `agentic-senior-core context "<task_description>"` (or `npx @ryuenn3123/agentic-senior-core context "<task_description>"`) to resolve scopes. Do not guess or hallucinate context.
+STOP. Before non-trivial tasks, MUST run `agentic-senior-core context "<task_description>"`. Do not guess context.
 
-Immediately emit a concise Bootstrap Receipt:
-- `loaded_files`: files actually read (exact paths from selectedRules/selectedPrompts only; zero hallucination)
-- `selected_rules`: files selected for this scope and why
-- `skipped_rules`: out-of-scope categories left unloaded
-- `unreachable_files`: required files that could not be read
-- `validation_plan`: expected checks before completion
+Immediately emit concise Bootstrap Receipt:
+- `loaded_files`: read paths
+- `selected_rules`: selected files & why
+- `skipped_rules`: out-of-scope
+- `unreachable_files`: missing required
+- `validation_plan`: expected checks
 
-Skip this step ONLY for trivial tasks (version bumps, typo fixes).
+Skip ONLY for trivial tasks (version bumps, typos).
 
 ## Command Economy
-Always prefix noisy shell commands: `ascx git status`, `ascx git diff`, `ascx npm test`, `ascx npm install`, `ascx npm run build`, `ascx tsc`, `ascx rg` searches. Use raw commands only for pipes, redirects, or commands not supported by ascx.
-Always read and apply `.agent-context/prompts/compact-natural-mode.md` for every final user-facing reply. Never repeat full command output; reference tee file paths when truncated.
+Use noisy forms: `ascx git status`, `ascx git diff`, `ascx npm test`. Raw commands only for pipes/unsupported. Apply `compact-natural-mode.md` for replies; reference tee paths when truncated.
 
 ## Layer Index
-### Layer 1: Rules (18 Files) [SCOPE-RESOLVED]
-Location: `.agent-context/rules/`.
-
-Load only relevant rule files. Do not read the entire rule directory by default.
-
-Available rules: `architecture.md` (`ARCH-*`, v4), `security.md` (`SEC-*`, v4), `performance.md` (`PERF-*`, v4), `error-handling.md` (`ERR-*`, v4), `testing.md` (`TEST-*`, v4), `api-docs.md` (`API-*`, v4), `microservices.md` (`SVC-*`, v4), `event-driven.md` (`EVT-*`, v4), `database-design.md` (`DATA-*`, v4), `realtime.md` (`RT-*`, v4), `frontend-architecture.md` (`FE-*`, v4), `docker-runtime.md` (`DOCK-*`, v4), `observability.md` (`OBS-*`, v4), `resilience.md` (`RES-*`, v4), `migrations.md` (`MIG-*`, v4), `background-jobs.md` (`JOB-*`, v4), `config-and-flags.md` (`CFG-*`, v4), `api-versioning.md` (`VER-*`, v4).
 
+### Layer 1: Rules (18 Files) [SCOPE-RESOLVED]
+Location: `.agent-context/rules/`. Load only relevant files.
+Available: `architecture.md`, `security.md`, `performance.md`, `error-handling.md`, `testing.md`, `api-docs.md`, `microservices.md`, `event-driven.md`, `database-design.md`, `realtime.md`, `frontend-architecture.md`, `docker-runtime.md`, `observability.md`, `resilience.md`, `migrations.md`, `background-jobs.md`, `config-and-flags.md`, `api-versioning.md`.
 
-For Docker or Compose work, load `docker-runtime.md` and verify the latest official Docker docs before authoring container assets. Also perform live web research for Docker and framework/package setup claims. For framework or package setup work, use the latest stable compatible dependency set and official setup flow unless a documented compatibility constraint blocks it; prefer official framework scaffolders when they create the supported project shape. New dependencies are allowed when they improve efficiency, delivery time, correctness, accessibility, UX, or maintainability. Do not treat dependency avoidance or vague performance fear as a default reason to skip a modern maintained library.
-
-Backend/API routing:
-- Data/schema/persistence: `architecture.md`, `database-design.md`, `migrations.md`, `performance.md`, `testing.md`.
-- Endpoint/API/error contracts: `architecture.md`, `api-docs.md`, `api-versioning.md`, `error-handling.md`, `observability.md`, `security.md`, `testing.md`.
-- Auth/secrets/uploads/permissions: `security.md`, `config-and-flags.md`, `error-handling.md`, `observability.md`, `testing.md`.
-- Queue/worker/cron/events/retry: `event-driven.md`, `background-jobs.md`, `resilience.md`, `database-design.md`, `error-handling.md`, `observability.md`, `performance.md`, `testing.md`.
-- Multi-service/distributed boundaries: `microservices.md`, `event-driven.md`, `database-design.md`, `api-docs.md`, `architecture.md`, `resilience.md`, `observability.md`, `performance.md`.
+For Docker or Compose work, load `docker-runtime.md` and verify the latest official Docker docs before authoring container assets. Also perform live web research for Docker and framework/package setup claims.
+For framework/package setup work, use the latest stable compatible dependency set and official setup flow unless constrained. New dependencies allowed to improve efficiency.
 
-Use the union once when scopes overlap. Do not create framework-specific governance adapters.
+Backend routing:
+- Data: `architecture.md`, `database-design.md`, `migrations.md`, `performance.md`, `testing.md`
+- Endpoint: `architecture.md`, `api-docs.md`, `api-versioning.md`, `error-handling.md`, `observability.md`, `security.md`, `testing.md`
+- Auth: `security.md`, `config-and-flags.md`, `error-handling.md`, `observability.md`, `testing.md`
+- Worker: `event-driven.md`, `background-jobs.md`, `resilience.md`, `database-design.md`, `error-handling.md`, `observability.md`, `performance.md`, `testing.md`
+- Distributed: `microservices.md`, `event-driven.md`, `database-design.md`, `api-docs.md`, `architecture.md`, `resilience.md`, `observability.md`, `performance.md`
 
 ### Layer 2: Runtime Decision Signals
-
-Runtime Decision Signals come from project context, repo evidence, and live research. Runtime signals are evidence gates, not style cues or popularity rankings.
-
-For fresh projects, recommend runtime/framework from the brief, constraints, and live official docs before coding. For existing projects, treat detected markers as evidence only. Ignore pattern frequency, external rankings, and remembered defaults. Do not default web projects to Next.js, Tailwind-only styling, shadcn/ui, Vite, or any familiar web stack by habit, and do not avoid them because of this guard when they are the strongest project fit.
+Runtime signals are evidence gates, not style cues. Recommend runtime/framework from brief and live official docs before coding. Treat existing project markers as evidence. Do not blindly default to familiar web stacks. Extract constraints and required docs first. Do not silently choose frameworks or architecture from offline heuristics. Ignore pattern frequency. If unresolved, produce a short recommendation from evidence and live official documentation before coding.
 
 ### Layer 3: Structural Planning Signals
-
-Structural Planning Signals use dynamic structural planning from repo context, docs, runtime constraints, and live research. Structural planning signals are not a hard whitelist.
-
-For new projects or modules, extract constraints, 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. Compare at least one plausible alternative when the strongest-looking option is a familiar web default and the user did not explicitly choose it.
+Use dynamic structural planning from repo context. Structural planning signals are not a hard whitelist.
 
 ### Layer 4: Execution Contracts
-
-Execution Contracts are dynamic execution contracts from prompts, review checklists, and policy thresholds. Resolve the active contract, then enforce mandatory checks before declaring completion.
+Enforce dynamic execution contracts from active prompt, checklists, and policies before declaring completion.
 
 ### Layer 5: Prompts
+Location: `.agent-context/prompts/`. Load matching prompt + `compact-natural-mode.md`:
+- `init-project.md`: create, scaffold
+- `refactor.md`: improve, fix
+- `review-code.md`: audit, analyze
+- `bootstrap-design.md`: ui, ux, layout, screen, tailwind, frontend, redesign
 
-Location: `.agent-context/prompts/`. Load the matching prompt only, plus `compact-natural-mode.md` as the default final-response contract:
-- `compact-natural-mode.md` -> final response shape, evidence preservation, and compact natural prose
-- `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 (compact design direction prompt with default detection, anchor selection, and creative commitments)
-
-For UI-only work, load `bootstrap-design.md` and `frontend-architecture.md` first; do not eagerly load unrelated backend-only rules unless the request crosses that boundary. The valid style context is current repo evidence, current brief, and current project docs. External references, prior-chat memory, unrelated-project visuals, and remembered screenshots are tainted unless the user makes them current-task constraints. Treat WCAG 2.2 AA as the hard compliance floor and APCA as advisory perceptual tuning only.
+For UI work, load `bootstrap-design.md` and `frontend-architecture.md` first; do not eagerly load unrelated backend-only rules. The valid style context is current repo evidence. External references, prior-chat memory, unrelated-project visuals, and remembered screenshots are tainted. Treat WCAG 2.2 AA as the hard compliance floor and APCA as advisory perceptual tuning only.
 
 ### Layer 6: Governance Modes
+Use dynamic governance context. Apply matching defaults.
 
-Governance Modes use dynamic governance context from state files, policies, and repo norms. Apply matching defaults only when relevant.
+### Layer 7: State
+Use `.agent-context/state/` for continuity/benchmarks. Use `onboarding-report.json`.
 
-### Layer 7: State and Benchmarks
-
-Use `.agent-context/state/` only when the task needs risk zones, dependency boundaries, benchmarks, or continuity metadata. For initialized projects, `.agent-context/state/onboarding-report.json` records selected profile, runtime evidence, architecture decision status, token optimization, and memory continuity.
-
-### Layer 8: Policies and Thresholds
-
-Use `.agent-context/policies/` for quality gates, release thresholds, and audit posture.
+### Layer 8: Policies
+Use `.agent-context/policies/` for quality gates. Apply matching defaults.
 
 ### Layer 9: Project Context
-
-Use root `README.md` as the public and developer entrypoint for every fresh or existing project. Use `docs/doc-index.md` as the compact routing map when `docs/` exists. Use `docs/` when present: `project-brief.md`, `architecture-decision-record.md`, `database-schema.md`, `api-contract.md`, `flow-overview.md`, `DESIGN.md`.
+Use root `README.md` as the public and developer entrypoint. Use `docs/doc-index.md` as the compact routing map.
 
 ## Mandatory Triggers
 
 ### 1. Documentation-First Mode
-
-Trigger: docs, documentation, dokumen, `docs/*`, architecture docs, flow docs, API docs, or "lengkapkan docs".
-
-1. Load `architecture.md`, `api-docs.md`, and only additional rules required by scope.
-2. Create or refine required docs first: root `README.md` for every fresh or existing project; `docs/doc-index.md` whenever `docs/` exists; `docs/project-brief.md`; `docs/architecture-decision-record.md`; `docs/flow-overview.md`; `docs/api-contract.md` for APIs, firmware endpoints, CLI commands, or web application flows; `docs/database-schema.md` for persistent data; and `docs/DESIGN.md` for UI scope.
-3. Use Mermaid.js as the default diagram format for all documentation diagrams (flowcharts, sequence, ER, C4, state). Embed as fenced `mermaid` code blocks. Do not use PlantUML, ASCII art diagrams, Graphviz DOT, or Structurizr DSL. When updating existing docs that contain prose-only descriptions, convert relevant sections to Mermaid diagrams in the same change.
-4. Use `docs/doc-index.md` as the compact read-routing map; add PRD, SRS, technical-design, or separate ERD only when justified. Write formal project docs in English by default.
+Trigger: docs, documentation, dokumen, `docs/*`, architecture docs, flow docs, API docs, "lengkapkan docs".
+1. Load `architecture.md`, `api-docs.md`, plus scope rules.
+2. Create or refine required docs first: root `README.md` for every fresh or existing project; `docs/doc-index.md` whenever `docs/` exists; `docs/project-brief.md`; `docs/architecture-decision-record.md`; `docs/flow-overview.md`; `docs/api-contract.md`; `docs/database-schema.md`; `docs/DESIGN.md`.
+3. Use Mermaid.js as the default diagram format. Convert prose to diagrams where relevant.
+4. Use `docs/doc-index.md` as routing map. Write formal project docs in English by default.
 5. Stop after documentation when the user only asked for docs. Do not write application, firmware, or UI code until the user asks or approves implementation; do not write application, firmware, or UI code before approval.
 
 ### 2. New Project Planning
-
 Trigger: create, build, new project, scaffold.
-
-1. Resolve relevant rules.
-2. Read `init-project.md`.
-3. Infer constraints, required docs, and boundaries from requirements, repo evidence, docs, and live research.
-4. Recommend runtime/architecture when unresolved.
-5. WAIT for user approval before generating code.
+Resolve rules -> Read `init-project.md` -> Infer constraints -> Recommend runtime -> WAIT for user approval.
 
 ### 3. Refactor Mode
-
 Trigger: refactor, improve, fix, clean up.
-
-1. Resolve relevant rules.
-2. Read `refactor.md`.
-3. Apply active prompt/checklist contracts.
-4. Propose a plan before edits.
-5. WAIT for approval.
+Resolve rules -> Read `refactor.md` -> Apply contracts -> Propose plan -> WAIT for user approval.
 
 ### 4. Code Review Mode
-
 Trigger: review, audit, check, analyze.
-
-Load `pr-checklist.md` and `architecture-review.md`, then report defects, risks, regressions, and missing tests first.
+Load `pr-checklist.md`, `architecture-review.md`. Report defects first.
 
 ### 5. UI Design Mode
-
 Trigger: ui, ux, layout, screen, tailwind, frontend, redesign.
-
-1. Read `bootstrap-design.md` and `frontend-architecture.md`. Read UI-relevant repo evidence from state, current UI code, and `docs/*`.
-2. Follow the three-step direction process in `bootstrap-design.md`: name defaults, choose anchor, commit to creative direction. If `docs/DESIGN.md` has an anti-repeat ledger, load previous directions as blocklist.
-3. Generate or refine `docs/DESIGN.md` before UI implementation. Keep context isolated; do not eagerly load unrelated backend-only rules.
-4. External websites are evidence for constraints and mechanics only. Do not copy layout rhythm, palette, component skin, or brand posture without explicit user approval.
+1. Read `bootstrap-design.md`, `frontend-architecture.md`, repo UI evidence.
+2. Follow `bootstrap-design.md` three-step direction process: name defaults, choose anchor, commit to creative direction. Check anti-repeat ledger in DESIGN.md.
+3. Refine `docs/DESIGN.md` before UI implementation.
+4. Do not copy layout rhythm/palette from external references blindly.
 
 ## Bounded Reflection
-For risky actions (file edits, public contracts, rule conflicts/refusals, release/publish gates, or security/data/API/testing/architecture boundaries), show this compact block before action or refusal:
-
+For risky actions, use:
 ```text
 REFLECTION
 Rules: ARCH-001, TEST-001
-Risk: one-line risk or conflict
-Action: one-line bounded next step
+Risk: one-line risk
+Action: one-line bounded step
 ```
-Use valid rule IDs only; do not quote full rule prose, expose hidden chain-of-thought, or require the block for trivial replies.
+Use valid rule IDs only. Do not expose hidden chain-of-thought.
 
 ## Definition of Done
-Never claim done without:
 1. Relevant rules applied.
-2. PR and architecture checklists considered.
-3. Universal SOP gates satisfied: public and developer root `README.md`; `docs/doc-index.md` when `docs/` exists; `docs/project-brief.md`; `docs/architecture-decision-record.md`; `docs/flow-overview.md`; `docs/database-schema.md` when persistent data exists; `docs/api-contract.md` when API or web application flows exist; plus `docs/DESIGN.md` for UI scope.
-4. If `.agent-context/state/active-memory.json` exists and material project progress happened, refresh it while preserving privacy rules and user-owned entries.
-5. Project validation passed through `npm run validate`.
-
-## Knowledge Inventory Checklist
-
-Verify reachability of relevant files in Layer 1 to Layer 9 before generating implementation code. If a required instruction file is missing or unreachable, halt and report the missing dependency.
-
-## Operating Gates
-
-- Before code: resolve active rules and contract.
-- Before PR: run review checklists.
-- Before deploy: check policy thresholds.
-- Before major refactor: read `architecture-map.md`.
-- Before UI implementation: confirm valid style context, design contract, and required docs.
+2. PR/architecture checklists considered.
+3. Universal SOP gates satisfied: root `README.md`; `docs/doc-index.md` when `docs/` exists; `docs/project-brief.md`; `docs/architecture-decision-record.md`; `docs/flow-overview.md`; `docs/database-schema.md`; `docs/api-contract.md`; `docs/DESIGN.md`.
+4. Refresh `.agent-context/state/active-memory.json`.
+5. `npm run validate` passed.
+
+## Operations
+- Verify Layer 1-9 reachability before code.
+- Branch from main (`feat/`, `fix/`, `docs/`, `chore/`). Squash merge PRs.
+- Never touch `.agentic-backup/`. Update `package-lock.json` via `ascx npm install`. Regenerate benchmarks via scripts.

package/bin/agentic-senior-core.js

@@ -16,7 +16,7 @@ import { runOptimizeCommand, parseOptimizeArguments } from '../lib/cli/commands/
 import { runInitCommand, parseInitArguments } from '../lib/cli/commands/init.mjs';
 import { runUpgradeCommand, parseUpgradeArguments } from '../lib/cli/commands/upgrade.mjs';
 import { runContextCommand } from '../lib/cli/commands/context.mjs';
-import { runDesignAntiRepeatAuditCommand } from '../lib/cli/commands/audit-design-anti-repeat.mjs';
+
 
 async function main() {
   const commandArgument = process.argv[2];
@@ -70,10 +70,7 @@ async function main() {
     return;
   }
 
-  if (commandArgument === 'audit:design-anti-repeat') {
-    const auditExitCode = await runDesignAntiRepeatAuditCommand(commandArguments);
-    exit(auditExitCode);
-  }
+
 
   console.error(`Unknown command: ${commandArgument}`);
   printUsage();

package/lib/cli/adaptive-context/catalog.mjs

@@ -141,6 +141,10 @@ export const RULE_FAMILY_CATALOG = [
       'middleware',
       'rapihin',
       'rapikan',
+      'simple',
+      'simplicity',
+      'modularity',
+      'elegance',
     ],
   },
   {