@ankhorage/devtools 2.0.8 → 2.0.9

package/README.md

@@ -3,7 +3,7 @@
 
 # @ankhorage/devtools
 
-![license: MIT](././paradox/badges/license.svg) ![npm: v2.0.8](././paradox/badges/npm.svg) ![runtime: bun](././paradox/badges/runtime.svg) ![typescript: strict](././paradox/badges/typescript.svg) ![eslint: checked](././paradox/badges/eslint.svg) ![prettier: checked](././paradox/badges/prettier.svg) ![build: checked](././paradox/badges/build.svg) ![tests: checked](././paradox/badges/tests.svg) ![paradox: warnings](././paradox/badges/docs.svg)
+![license: MIT](././paradox/badges/license.svg) ![npm: v2.0.9](././paradox/badges/npm.svg) ![runtime: bun](././paradox/badges/runtime.svg) ![typescript: strict](././paradox/badges/typescript.svg) ![eslint: checked](././paradox/badges/eslint.svg) ![prettier: checked](././paradox/badges/prettier.svg) ![build: checked](././paradox/badges/build.svg) ![tests: checked](././paradox/badges/tests.svg) ![paradox: warnings](././paradox/badges/docs.svg)
 
 Shared tooling, repository automation, and agent standards for Ankhorage TypeScript projects
 

package/dist/tools/skills/assets/ankhorage-project-structure/SKILL.md

@@ -53,9 +53,16 @@ Valid profiles include:
 - generated standalone application;
 - an explicitly documented repository-specific profile such as Studio.
 
-A package may start flat. Introduce `domain/`, `application/`, `ports/`, `adapters/`,
-`composition/`, `features/`, or `core/` only when those names communicate a real architectural
-role. Once a vocabulary is introduced, its combinations must be coherent:
+Implementation-owning Ankhorage packages are feature-first. Product, domain, and package
+capabilities belong below `src/features/<feature>/`; do not place feature implementation modules
+directly below `src/`. Keep only deliberate public facades and genuinely package-wide ownership
+such as `src/types/`, `src/constants/`, and `src/utils/` at the source root. Contracts-only,
+reusable UI/design-system, generated-application, and explicitly documented repository-specific
+profiles may use their dedicated taxonomy instead of inventing fake features.
+
+Inside each feature, introduce `domain/`, `application/`, `ports/`, `adapters/`, or
+`composition/` only when those names communicate a real architectural role. Do not create empty
+hexagonal layers for symmetry. Once a vocabulary is introduced, its combinations must be coherent:
 
 - `domain/` may stand alone and must remain independent from outer mechanisms;
 - `application/` coordinates use cases and may depend inward on domain policy and required ports;
@@ -82,8 +89,12 @@ Repository-root `examples/` contains complete user-facing examples. Each example
 subdirectory. Test-only fixtures remain test-owned.
 
 Package-level delivery edges such as `src/cli/`, `src/host/`, `src/app/`, or `src/platform/`
-remain thin adapters/composition boundaries. The filesystem below `src/cli/commands/` mirrors the
-public Ankh command path, and command modules parse input, invoke package behavior, and render output.
+remain thin adapters/composition boundaries outside feature ownership. Every public Ankh command
+implementation must live below `src/cli/commands/`, and that filesystem mirrors the public command
+path after the package prefix. For example, `ankh rules config validate` maps to
+`src/cli/commands/config/validate.ts`. CLI provider/index modules register and compose commands;
+they must not contain the command's application or domain behavior. Command modules parse input,
+invoke the owning feature boundary, and render output.
 
 Keep only deliberate public facades directly under `src/`. Public package subpaths must map to
 explicit package exports; generic barrels are not an excuse to bypass ownership.

package/dist/tools/skills/assets/ankhorage-project-structure/references/architecture-profiles.md

@@ -3,25 +3,28 @@
 Choose the profile from actual ownership and consumers. Profiles define allowed vocabulary and
 dependency direction; they are not templates that require every listed directory.
 
-## Simple, value, or contracts library
+## Simple or value library
 
-Use for portable types, deterministic values, parsers, constants, algorithms, and small libraries
-without application orchestration.
+Use for deterministic values, parsers, constants, algorithms, and small runtime libraries without
+application orchestration. Runtime-owning libraries are still feature-first: each coherent package
+capability belongs below `src/features/<feature>/`, but a simple feature does not need hexagonal
+role directories when it has no orchestration or external edge.
 
-Typical forms:
+Typical form:
 
 ```text
 src/
   index.ts
-  <domain-or-topic>/
+  features/
+    <feature>/
   types/
   constants/
   utils/
 ```
 
 Do not invent ports, adapters, application, or composition layers when there is no external edge to
-abstract. Contracts packages additionally keep public declarations serializable and free of runtime
-implementation.
+abstract. Contracts-only repositories follow the dedicated Contracts repository profile from the
+main project-structure skill instead of this runtime-library profile.
 
 ## Reusable UI or design-system library
 
@@ -44,28 +47,13 @@ components or registries. Provider execution belongs outside reusable presentati
 ## Application, engine, or hybrid package
 
 Use when the package owns use cases, state transitions, external systems, or several delivery edges.
-Domain-first and feature-first organization are both valid when coherent.
-
-Domain-first example:
-
-```text
-src/
-  <domain>/
-    domain/
-    application/
-    ports/
-    adapters/
-    composition/
-  cli/
-  host/
-  app/
-  platform/
-```
-
-Feature-first example:
+These packages are feature-first: every product/domain/package capability is owned below
+`src/features/<feature>/`. Do not use top-level domain folders or flat `src/*.ts` implementation
+modules as an alternative ownership model.
 
 ```text
 src/
+  index.ts
   features/
     <feature>/
       domain/
@@ -74,6 +62,10 @@ src/
       adapters/
       composition/
   cli/
+    commands/
+  types/
+  constants/
+  utils/
 ```
 
 Only create the role directories that the capability actually needs. A pure domain feature can stop
@@ -81,35 +73,45 @@ at `domain/`; an in-memory use case need not invent an outbound adapter.
 
 ## Provider or platform adapter package
 
-Use when the package deliberately implements an external technology boundary:
+Use when the package deliberately implements an external technology boundary. Provider capabilities
+are still feature-owned; concrete technology remains at the feature's outer adapter boundary:
 
 ```text
 src/
-  contracts/
-  planning/
-  adapters/
-  composition/
+  features/
+    <capability>/
+      domain/
+      application/
+      ports/
+      adapters/
+      composition/
   cli/
+    commands/
 ```
 
 Portable configuration and planning stay independent from SDK/runtime values. Concrete provider code
-stays in adapters.
+stays in adapters, and package-level delivery edges remain outside the feature.
 
 ## Tooling package
 
-Command-centric tooling may use:
+Command-centric tooling remains feature-first for owned capabilities while the CLI stays an outer
+delivery edge:
 
 ```text
 src/
+  features/
+    <capability>/
+      domain/
+      application/
+      ports/
+      adapters/
+      composition/
   cli/
-  policy/
-  application/
-  adapters/
-  composition/
+    commands/
 ```
 
 Policy remains deterministic. Filesystem, process, registry, network, and GitHub behavior stay at
-the edge.
+the feature edge or package delivery edge rather than leaking into inner policy.
 
 ## Generated standalone application
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ankhorage/devtools",
-  "version": "2.0.8",
+  "version": "2.0.9",
   "description": "Shared tooling, repository automation, and agent standards for Ankhorage TypeScript projects",
   "license": "MIT",
   "homepage": "https://github.com/ankhorage/devtools#readme",