@juancr11/sibu 0.9.6 → 0.10.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@juancr11/sibu",
-  "version": "0.9.6",
+  "version": "0.10.0",
   "description": "CLI for setting up a local AI-augmented development workflow.",
   "repository": {
     "type": "git",

package/templates/AGENTS.md

@@ -14,6 +14,7 @@
 ## Agent-specific instructions
 
 - Before any task that writes or modifies code, propose a brief plan and wait for user confirmation once per requested task.
+- Exception: when the user asks to plan, implement, execute, continue, or work through a User Story or Epic with `ai-implementation-plan-executor`, that request is confirmation to generate any missing implementation plan and begin execution immediately. Do not require a separate plan approval gate; wait only for the story-level review after implementation finishes.
 - For read-only work, research, planning, documentation-only edits, or other non-code changes, do not ask for confirmation unless the action is destructive, risky, ambiguous, or explicitly requires user approval.
 - After confirmation, proceed with all agreed in-scope changes without re-asking.
 - Ask again only if the scope changes materially, the approach becomes materially more complex or risky, or the user explicitly asks to review before continuing.
@@ -36,7 +37,7 @@ Keep responses concise by default, but spend the context needed for correctness,
 
 ## Skill routing
 
-For planned product/feature work, use this pipeline: product vision -> deep module map -> feature brief -> technical design -> optional UX -> epics/stories -> AI implementation plan -> AI executor. Narrow code fixes and small local changes do not require the full pipeline unless product scope, module ownership, or architecture direction is unclear.
+For planned product/feature work, use this pipeline: product vision -> deep module map -> feature brief -> technical design -> optional UX -> epics/stories -> AI executor. The executor creates a missing AI implementation plan and then executes it immediately when a story or Epic is requested for planning, implementation, or continuation. Narrow code fixes and small local changes do not require the full pipeline unless product scope, module ownership, or architecture direction is unclear.
 
 - For any code-writing task, use `clean-code`.
 - For requests to create, revise, or clarify a product vision, product strategy narrative, product north star, positioning, product principles, product voice, target user definition, product boundaries, or success signals, use `product-vision-writer`.
@@ -44,8 +45,8 @@ For planned product/feature work, use this pipeline: product vision -> deep modu
 - For requests to create, revise, or clarify a business-level feature brief after Deep Module Map work, feature definition, feature scope, MVP feature boundaries, business acceptance criteria, or product-level feature rationale, use `feature-brief-writer`.
 - For requests to create, revise, or clarify a technical design, implementation-oriented design doc, architecture approach, technical tradeoffs, technical risks, or implementation plan for an approved feature, use `technical-design-writer`.
 - For requests to create Epics, User Stories, Scrum planning artifacts, backlog slices, or delivery plans from an approved feature brief and technical design, use `scrum-master-planner`.
-- For requests to turn a specific User Story into an implementation checklist, coding plan, step-by-step execution plan, or baby-step plan, use `ai-implementation-planner`.
-- For requests to implement, execute, continue, or work through a specific User Story under `docs/features/<feature-slug>/epics/<epic-slug>/stories/<order>-<story-slug>.md` or an existing story implementation plan under `docs/features/<feature-slug>/epics/<epic-slug>/stories/<order>-<story-slug>.impl_plan/`, use `ai-implementation-plan-executor`; when the story plan is missing, the executor should create it with `ai-implementation-planner` and immediately continue into implementation without a separate plan approval gate.
+- For explicit planning-only requests to turn a specific User Story into an implementation checklist, coding plan, step-by-step execution plan, or baby-step plan without implementation, use `ai-implementation-planner` and stop after writing the plan. Treat a request as planning-only only when the user explicitly says planning-only, "do not implement," or asks to create the plan without execution.
+- For requests to plan, implement, execute, continue, or work through a specific User Story under `docs/features/<feature-slug>/epics/<epic-slug>/stories/<order>-<story-slug>.md`, an Epic, or an existing story implementation plan under `docs/features/<feature-slug>/epics/<epic-slug>/stories/<order>-<story-slug>.impl_plan/`, use `ai-implementation-plan-executor`; when the story plan is missing, the executor must create it with `ai-implementation-planner` and immediately continue into implementation without a separate plan approval gate.
 {{OPTIONAL_SKILL_ROUTING}}
 
 ## Sibu maintenance

package/templates/manifest.json

@@ -1,11 +1,11 @@
 {
-  "templateVersion": "84",
+  "templateVersion": "89",
   "templates": {
     "AGENTS.md": {
-      "version": "26",
+      "version": "28",
       "description": "Project-level agent instructions and Sibu maintenance guidance.",
       "changes": [
-        "Updates implementation routing so missing story plans are generated and executed immediately without a separate plan approval gate."
+        "Routes story and Epic planning requests to the executor by default so generated plans are implemented immediately unless planning-only is explicit."
       ]
     },
     ".codex/config.toml": {
@@ -73,10 +73,10 @@
       ]
     },
     "skills/technical-design-writer/SKILL.md": {
-      "version": "15",
+      "version": "16",
       "description": "Mandatory technical design writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Updates technical design guidance to translate selected Deep Modules into implementation boundaries."
+        "Requires technical designs crossing framework boundaries to name the allowed application/orchestration entrypoint and forbidden lower-level dependencies."
       ]
     },
     "skills/typescript/SKILL.md": {
@@ -101,24 +101,24 @@
       ]
     },
     "skills/architecture/ddd-hexagonal/SKILL.md": {
-      "version": "7",
+      "version": "8",
       "description": "Selectable back-end architecture skill for DDD and Hexagonal Architecture.",
       "changes": [
-        "Adds anti-corruption adapter guidance for translating external models at infrastructure boundaries."
+        "Adds a framework-agnostic adapter dependency rule requiring delivery entrypoints to call application/orchestration boundaries instead of infrastructure or domain workflow internals."
       ]
     },
     "skills/architecture/command-pattern/SKILL.md": {
-      "version": "5",
+      "version": "6",
       "description": "Selectable architecture skill for command-oriented vertical slices using Command Pattern, Hexagonal Architecture, and DDD principles.",
       "changes": [
-        "Clarifies that Deep Modules hide implementation complexity behind small interfaces and are not product categories by themselves."
+        "Adds a framework-agnostic entrypoint dependency rule requiring delivery adapters to create commands and call handlers or dispatchers instead of infrastructure, SDKs, repositories, or domain workflow internals."
       ]
     },
     "skills/nextjs/SKILL.md": {
-      "version": "1",
+      "version": "3",
       "description": "Selectable framework skill for Next.js App Router and framework-specific behavior.",
       "changes": [
-        "Adds an optional Next.js skill for projects that use App Router pages, layouts, route handlers, metadata, and Server/Client Component boundaries."
+        "Keeps Next.js boundary guidance architecture-agnostic by referring to the selected orchestration/application boundary instead of naming a specific architecture."
       ]
     },
     "skills/react/SKILL.md": {
@@ -136,17 +136,17 @@
       ]
     },
     "skills/ai-implementation-planner/SKILL.md": {
-      "version": "13",
+      "version": "15",
       "description": "Mandatory AI implementation planner skill for turning one approved User Story into small, story-local implementation step files.",
       "changes": [
-        "Clarifies that executor handoffs can come from the next story or next Epic and still continue without plan approval."
+        "Clarifies that the planner is normally an executor helper and stops after planning only when planning-only is explicit."
       ]
     },
     "skills/ai-implementation-plan-executor/SKILL.md": {
-      "version": "20",
+      "version": "22",
       "description": "Mandatory AI implementation plan executor skill for implementing full story plans before story-level review and commit.",
       "changes": [
-        "Changes next-Epic continuation to choose the next logical Epic based on dependencies, readiness, risk, and value instead of filename order."
+        "Clarifies that story and Epic planning requests are confirmation for executor implementation."
       ]
     },
     "skills/ai-prompt-engineer-master/SKILL.md": {

package/templates/skills/ai-implementation-plan-executor/SKILL.md

@@ -105,7 +105,8 @@ If the initial User Story has no matching `.impl_plan/`, or the initial `.impl_p
 1. Apply `ai-implementation-planner` to create or repair the story-local implementation plan.
 2. Quality-check that the generated plan has ordered step files for exactly that story.
 3. Immediately begin executing the generated plan with this executor.
-4. Do not ask the user to approve the plan before implementation; the only required approval is the story-level review after implementation finishes.
+4. Treat the planner as an internal helper, not a user-visible stopping point.
+5. Do not ask the user to approve the plan before implementation; the only required approval is the story-level review after implementation finishes.
 
 If required source context is missing:
 
@@ -118,7 +119,7 @@ If required source context is missing:
 
 Work through the full story plan in filename order, one step at a time, without asking for review or approval between steps.
 
-When a valid implementation plan exists, begin implementing the first unapproved step immediately. If a plan was just generated by `ai-implementation-planner`, begin implementing it immediately. Do not ask for pre-implementation confirmation or plan approval before changing code. This is an explicit exception to repository-level instructions that normally require confirmation before code changes: selecting this executor skill, asking to implement or continue a story/Epic, or providing a valid plan is the user's confirmation to implement the full story plan.
+When a valid implementation plan exists, begin implementing the first unapproved step immediately. If a plan was just generated by `ai-implementation-planner`, begin implementing it immediately. Do not ask for pre-implementation confirmation or plan approval before changing code. This is an explicit exception to repository-level instructions that normally require confirmation before code changes: selecting this executor skill, asking to plan, implement, execute, or continue a story/Epic, or providing a valid plan is the user's confirmation to implement the full story plan.
 
 A step file is considered approved only when it contains this section:
 

package/templates/skills/ai-implementation-planner/SKILL.md

@@ -7,7 +7,7 @@ description: Turn one approved User Story Markdown file into LLM-sized implement
 
 ## Purpose
 
-Turn one approved User Story into concrete Markdown step files an AI coding agent can execute safely and completely. This skill owns implementation planning for one story at a time, not product scope, technical design decisions, Scrum planning, or code implementation. After writing the plan, it does not require a separate plan approval gate; implementation may continue immediately through `ai-implementation-plan-executor` when the user requested execution or Epic continuation.
+Turn one approved User Story into concrete Markdown step files an AI coding agent can execute safely and completely. This skill owns implementation planning for one story at a time, not product scope, technical design decisions, Scrum planning, or code implementation. This planner is normally an internal helper for `ai-implementation-plan-executor`; after writing a valid plan, implementation must continue immediately through the executor unless the user explicitly requested planning-only.
 
 ## Pipeline Contract
 
@@ -29,7 +29,7 @@ Turn one approved User Story into concrete Markdown step files an AI coding agen
 - The user does not provide or clearly identify exactly one User Story file.
 - Any required source artifact is missing, incomplete, or invalid in a way its owning stage should repair.
 - The story or feature has UI impact and `ux.md` is missing; direct the user to `ux-expert`.
-- The request is to write production code, execute an implementation plan, create stories, or perform another pipeline stage.
+- This planner was invoked directly for a request that should route to another pipeline stage, such as writing production code, executing an existing implementation plan, creating stories, or performing another pipeline stage.
 
 ### What this skill must not do
 
@@ -37,7 +37,7 @@ Turn one approved User Story into concrete Markdown step files an AI coding agen
 - Do not modify prior-stage artifacts.
 - Do not reread `docs/deep-module-map.md` by default; trust `technical_design.md` for Deep Module implementation boundaries.
 - Do not infer implementation scope from an Epic brief, feature brief, or technical design without exactly one User Story.
-- Do not write production code directly from this planner; hand off to `ai-implementation-plan-executor` for implementation.
+- Do not write production code directly from this planner; hand off to `ai-implementation-plan-executor` for implementation. The executor is the orchestrator for planning, implementation, execution, continuation, and combined plan-and-execute requests.
 
 ## Required input
 
@@ -242,9 +242,9 @@ Before finishing, verify:
 
 ### 6. Continue or report
 
-After writing and quality-checking the implementation step files, do not ask for plan approval before execution. If the user asked to implement, execute, continue, or work through the story or Epic, immediately hand off to `ai-implementation-plan-executor` for the newly created plan in the same turn. The user's execution request plus a valid generated plan is enough pre-implementation confirmation; the only required user approval is the story-level review after execution finishes.
+After writing and quality-checking the implementation step files, do not ask for plan approval before execution. Unless the user explicitly requested planning-only, immediately hand off to `ai-implementation-plan-executor` for the newly created plan in the same turn. The user's story or Epic planning/execution request plus a valid generated plan is enough pre-implementation confirmation; the only required user approval is the story-level review after execution finishes.
 
-If the user asked only to create a plan and did not ask for implementation, stop after creating the plan and report where it was written. Make clear that no plan approval is required before a later executor run.
+If the user explicitly asked for planning-only, said not to implement, or asked to create the plan without execution, stop after creating the plan and report where it was written. Make clear that no plan approval is required before a later executor run.
 
 When this skill is invoked as the next-story or next-Epic planning handoff from `ai-implementation-plan-executor`, create the plan and immediately return control to the executor so it can implement that story without a plan-review gate.
 

package/templates/skills/architecture/command-pattern/SKILL.md

@@ -81,6 +81,37 @@ The Handler must be "blind" to the entrypoint. It should not know if it is being
 ### Rule 4: Thin Entrypoints
 Entrypoints (CLI/API) are responsible for Syntactic Validation (is the input the right type?). Handlers are responsible for Semantic Validation (does this operation make sense in the current state of the system?).
 
+### Rule 5: Entrypoints Call Commands, Not Lower Layers
+Entrypoints are driving adapters. Examples include CLI commands, HTTP routes, Next.js App Router files, server actions, queue consumers, jobs, webhooks, RPC handlers, and GraphQL resolvers.
+
+An entrypoint may:
+- adapt framework or transport input into a Command
+- call the feature Handler directly, or call an application-level command dispatcher/orchestration API
+- translate the Result into a framework or transport response
+
+An entrypoint must not directly import or call:
+- infrastructure adapters
+- database clients or repository implementations
+- SDK clients
+- persistence models or external API response shapes
+- another feature-slice's internals
+- domain workflow logic that bypasses the Handler
+
+Allowed flow:
+
+```txt
+entrypoint / framework adapter -> Command -> Handler / dispatcher -> Ports -> infrastructure adapters
+```
+
+Forbidden flow:
+
+```txt
+entrypoint / framework adapter -> infrastructure / database / SDK / repository implementation
+entrypoint / framework adapter -> domain workflow internals that bypass the Handler
+```
+
+If dependency wiring needs infrastructure implementations, prefer a composition/bootstrap module or small factory that constructs the Handler. Keep request handling, command creation, and result translation separate from infrastructure behavior.
+
 ---
 
 ## 4. Implementation Workflow

package/templates/skills/architecture/ddd-hexagonal/SKILL.md

@@ -95,6 +95,34 @@ This means:
 
 If business logic needs a DB client, SDK response, HTTP object, or framework context directly, the boundary is probably wrong.
 
+## Framework adapter dependency rule
+
+Framework code is a driving adapter. Examples include HTTP routes, controllers, Next.js App Router files, server actions, CLI commands, queue consumers, jobs, webhooks, RPC handlers, and GraphQL resolvers.
+
+Framework adapters may adapt framework input/output and call the application/orchestration boundary. They must not directly import or call:
+
+- repository implementations or database clients
+- SDK clients or infrastructure adapters
+- persistence models or external API response shapes
+- domain internals that perform a business workflow outside an application use case
+- other delivery/framework adapters
+
+Allowed flow:
+
+```txt
+framework adapter -> application use case / orchestration API -> domain + ports
+infrastructure adapter -> application/domain port contracts
+```
+
+Forbidden flow:
+
+```txt
+framework adapter -> infrastructure / database / SDK / repository implementation
+framework adapter -> domain workflow internals that bypass the application boundary
+```
+
+When planning or implementing a feature, name the application/orchestration API each framework entrypoint is allowed to call. Add an explicit allow/deny import list when the boundary could be ambiguous.
+
 ## Domain modeling: entity, value object, or neither
 
 Do not force DDD labels onto every concept. Use them only when they buy clarity, express real business meaning, or protect invariants.

package/templates/skills/nextjs/SKILL.md

@@ -44,9 +44,10 @@ Add `"use client"` only for code that needs client-side capabilities, such as:
 Prefer isolating the smallest interactive subtree into a Client Component rather than turning a whole page or layout into a Client Component.
 
 ### 4. Keep `src/app/**` thin
-- Treat `src/app/**` as a framework boundary.
-- Pages and route handlers should call application/domain code instead of containing business logic.
-- Keep request parsing, response formatting, redirects, and framework concerns in `src/app/**`.
+- Treat `src/app/**` as a framework adapter boundary.
+- When an architecture skill or technical design defines an orchestration/application boundary, App Router files may call only that boundary.
+- Pages, layouts, route handlers, Server Actions, and metadata functions must not bypass the selected architecture's dependency rules.
+- Keep request parsing, response formatting, redirects, rendering decisions, and framework concerns in `src/app/**`.
 - Move reusable business behavior out of App Router files.
 
 ### 5. Route handlers are framework adapters
@@ -54,6 +55,7 @@ Prefer isolating the smallest interactive subtree into a Client Component rather
 - Use the Web `Request` and `Response` APIs.
 - Keep handlers focused on HTTP concerns: parse input, call application behavior, and return a stable response.
 - Do not put backend business rules directly in route handlers.
+- Do not import infrastructure, database clients, repository implementations, SDK wrappers, persistence models, or external API shapes directly from App Router files unless the selected architecture explicitly allows it.
 
 ### 6. Use Next.js error and empty-state conventions
 - Use `notFound()` for route resources that genuinely do not exist.

package/templates/skills/technical-design-writer/SKILL.md

@@ -72,6 +72,8 @@ Translate product intent into implementation direction.
 
 Deep Modules answer “where does this implementation work belong?” Architecture guidance answers “how is that module structured internally?” Translate the feature brief's selected Deep Modules into implementation boundaries appropriate for the selected architecture. Capture those boundaries in the technical design so downstream Scrum planning, implementation planning, and execution can trust the technical design instead of rereading the Deep Module Map by default.
 
+When a feature crosses a framework or delivery boundary, include the allowed orchestration/application entrypoint and the forbidden lower-level dependencies. Keep this framework-agnostic: name roles like framework adapter, application/orchestration boundary, domain, port, and infrastructure, then add concrete project paths only where useful.
+
 Prefer:
 
 - concise decisions over long explanation
@@ -143,6 +145,8 @@ Use this structure as a starting point. Delete sections that do not add value.
 
 <Explain how the selected Deep Modules translate into architecture, module, command, file, or implementation boundaries when that affects downstream work.>
 
+<For framework/delivery entrypoints, state the application/orchestration API they may call and the lower-level layers, modules, or paths they must not call directly.>
+
 ## Validation
 <Focused test/build/manual checks.>