@juancr11/sibu 0.9.7 → 0.10.0

package/package.json

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

package/templates/manifest.json

@@ -1,5 +1,5 @@
 {
-  "templateVersion": "86",
+  "templateVersion": "89",
   "templates": {
     "AGENTS.md": {
       "version": "28",
@@ -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": {

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.>