@ankhorage/devtools 1.14.4 → 1.14.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -2,5 +2,6 @@ export declare const agentsManagedFiles: readonly [{
|
|
|
2
2
|
readonly relativePath: "AGENTS.md";
|
|
3
3
|
readonly render: typeof renderAgentsFile;
|
|
4
4
|
}];
|
|
5
|
+
/*** Render mandatory repository instructions from the target package identity. */
|
|
5
6
|
declare function renderAgentsFile(targetDirectory: string): Promise<string>;
|
|
6
7
|
export {};
|
|
@@ -6,6 +6,7 @@ export const agentsManagedFiles = [
|
|
|
6
6
|
render: renderAgentsFile,
|
|
7
7
|
},
|
|
8
8
|
];
|
|
9
|
+
/*** Render mandatory repository instructions from the target package identity. */
|
|
9
10
|
async function renderAgentsFile(targetDirectory) {
|
|
10
11
|
const manifest = await readPackageManifest(targetDirectory);
|
|
11
12
|
const packageName = readNonEmptyString(manifest.name) ?? 'Package name not declared';
|
|
@@ -33,11 +34,25 @@ published public APIs and declared dependencies, never sibling source files.
|
|
|
33
34
|
Current-runtime error handling and canonical database or infrastructure migrations remain valid
|
|
34
35
|
when they support states that the current architecture can intentionally produce.
|
|
35
36
|
|
|
36
|
-
##
|
|
37
|
+
## Required repository instructions
|
|
37
38
|
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
39
|
+
Before changing any file, read this \`AGENTS.md\` completely and inspect \`.agents/skills/\`.
|
|
40
|
+
For every change, load and follow both baseline repository skills before making changes:
|
|
41
|
+
|
|
42
|
+
1. \`.agents/skills/ankhorage-coding-rules/SKILL.md\`
|
|
43
|
+
2. \`.agents/skills/ankhorage-project-structure/SKILL.md\`
|
|
44
|
+
|
|
45
|
+
Load and follow every additional repository-local skill relevant to the task, including skills
|
|
46
|
+
required by either baseline skill. Continue to follow these instructions and skills through
|
|
47
|
+
validation and delivery; do not substitute remembered, globally installed, or generic guidance for
|
|
48
|
+
the repository-local versions.
|
|
49
|
+
|
|
50
|
+
## Documentation
|
|
51
|
+
|
|
52
|
+
\`README.md\` and the \`paradox/\` documentation tree are generated by \`@ankhorage/paradox\`.
|
|
53
|
+
Never edit generated documentation directly. Update the owning Paradox \`/*** ... */\` comments in
|
|
54
|
+
\`src\`, including \`@readme\` tags where the content belongs in the README, then run \`bun docs\`
|
|
55
|
+
and commit the regenerated artifacts.
|
|
41
56
|
|
|
42
57
|
## Pull requests
|
|
43
58
|
|
|
@@ -38,8 +38,10 @@ exceptions or replaced by generic preferences from this skill.
|
|
|
38
38
|
validation pass.
|
|
39
39
|
- Resolve size, complexity, and related findings around cohesive responsibilities and clear data
|
|
40
40
|
flow. Do not split a function or file mechanically just to cross a threshold.
|
|
41
|
-
-
|
|
42
|
-
|
|
41
|
+
- Use functional programming by default: declare bindings with `const`, not `let`; write pure
|
|
42
|
+
functions with explicit inputs and outputs; and use immutable data and updates. Keep side effects
|
|
43
|
+
explicit and at system boundaries. Mutation or reassignment is allowed only for a clearly
|
|
44
|
+
justified boundary or demonstrated performance-critical path, and must remain locally contained.
|
|
43
45
|
- Keep one canonical implementation. Do not add compatibility aliases, dual paths, historical-state
|
|
44
46
|
fallbacks, or sibling-source imports.
|
|
45
47
|
|
|
@@ -1,28 +1,40 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ankhorage-project-structure
|
|
3
3
|
description: >
|
|
4
|
-
Define, review, or implement the standard source structure of Ankhorage repositories. Use for feature ownership, CLI layout, hexagonal boundaries, source-module naming, type ownership, utilities, or package entrypoints.
|
|
4
|
+
Define, review, or implement the standard source structure of Ankhorage repositories. Use for feature ownership, CLI layout, hexagonal boundaries, source-module naming, Contracts ownership, type ownership, utilities, or package entrypoints.
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Ankhorage Project Structure
|
|
8
8
|
|
|
9
9
|
## Applicability
|
|
10
10
|
|
|
11
|
-
This skill applies to every Ankhorage repository
|
|
11
|
+
This skill applies to every Ankhorage repository.
|
|
12
12
|
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
13
|
+
### Contracts repository profile
|
|
14
|
+
|
|
15
|
+
If the current repository is `ankhorage/contracts`, apply only this profile:
|
|
16
|
+
|
|
17
|
+
- The repository may contain only portable, serializable contracts expressed as interfaces and
|
|
18
|
+
types. Every field must be serializable and reconstructable without executable behavior or
|
|
19
|
+
repository-local runtime objects. Do not add call signatures, function-valued properties,
|
|
20
|
+
functions, classes, constants, enums, mutable state, adapters, framework objects, or
|
|
21
|
+
implementation helpers.
|
|
22
|
+
- A contract belongs in this repository only when it is required across multiple repositories. A
|
|
23
|
+
current or coordinated change MUST identify at least two consuming repositories. Keep
|
|
24
|
+
single-repository types with their owning repository; anticipated reuse alone is not sufficient.
|
|
25
|
+
- Consumers import contracts through published public subpaths and declared dependencies, never
|
|
26
|
+
sibling source files or duplicated local declarations.
|
|
27
|
+
|
|
28
|
+
After enforcing this profile, stop before the remaining source-layout, implementation, utility,
|
|
29
|
+
and migration rules; they do not apply to `ankhorage/contracts`.
|
|
17
30
|
|
|
18
31
|
## Required skills
|
|
19
32
|
|
|
20
|
-
Before structural work
|
|
21
|
-
exports, then load
|
|
22
|
-
|
|
33
|
+
Before structural work outside `ankhorage/contracts`, read the repository `AGENTS.md`, inspect its
|
|
34
|
+
source tree and public exports, then load the required Hexagonal Architecture skill from the
|
|
35
|
+
repository root. Do not resolve it relative to this skill's own installation location:
|
|
23
36
|
|
|
24
|
-
1. `<repo-root>/.agents/skills/
|
|
25
|
-
2. `<repo-root>/.agents/skills/hexagonal-architecture/SKILL.md`
|
|
37
|
+
1. `<repo-root>/.agents/skills/hexagonal-architecture/SKILL.md`
|
|
26
38
|
|
|
27
39
|
## Required source layout
|
|
28
40
|
|
|
@@ -128,7 +140,7 @@ whether a barrel happens to re-export it:
|
|
|
128
140
|
|
|
129
141
|
1. **Used by one implementation module:** keep the type directly below the function that owns it, without `export`. Its private helpers can use the same local type. A test does not justify exporting an implementation-private type; test through the function boundary.
|
|
130
142
|
2. **Reused within the repository:** put related types together in `src/types/<topic>.ts` and use type-only imports. Name the file for a cohesive topic, not for each individual type. Such a file may export multiple related types/interfaces and contains no runtime implementation. Do not mix type-only files among feature functions or `utils/`, and do not create one global catch-all file.
|
|
131
|
-
3. **Shared across repositories:** the
|
|
143
|
+
3. **Shared across repositories and serializable:** when at least two repositories require the same portable data declaration, it belongs in `@ankhorage/contracts` at the owning topic's public subpath. Consumers import that contract through a declared dependency, not another repository's source or a duplicated local declaration. Keep non-serializable API types with their implementation-owning package and consume them through that package's public API. Keep framework-specific adapters separate from the portable shared contract.
|
|
132
144
|
|
|
133
145
|
Inspect published API declarations and real consumer imports before privatizing or relocating a
|
|
134
146
|
type. A public boundary type is not private just because only one implementation uses it locally.
|
|
@@ -165,14 +177,23 @@ belong together in `ankhorage/navigator/src/constants/navigator.ts`.
|
|
|
165
177
|
`utils/` is the only utility directory name. Do not create `shared/`, `helper/`, `helpers/`,
|
|
166
178
|
`common/`, or equivalent catch-all folders. It is not a destination for every pure function or type.
|
|
167
179
|
|
|
180
|
+
Apply **reuse before implementation** and **shared by default** before choosing a local owner. For
|
|
181
|
+
every function that could reasonably be reused across repositories, you MUST first inspect the
|
|
182
|
+
published `@ankhorage/utility` public API and its owning topic. Reuse the existing export when its
|
|
183
|
+
semantics match. If the function is missing and is generic without product, manifest, or framework
|
|
184
|
+
policy, implement, test, and export it from the appropriate Utility topic, then consume that public
|
|
185
|
+
export through a declared dependency. Do not duplicate it locally or add a forwarding wrapper.
|
|
186
|
+
`isRecord` from `@ankhorage/utility/object` is one motivating example of this general rule, not a
|
|
187
|
+
special case.
|
|
188
|
+
|
|
168
189
|
- Used by one module: keep the helper private below its owning function.
|
|
169
190
|
- Reused only inside a feature: keep it in that feature's `utils/`.
|
|
170
191
|
- Shared across features but tied to this package's capability or policy: use `src/utils/`.
|
|
171
192
|
Navigator topology traversal or Expo Router-specific validation does not become a general utility
|
|
172
193
|
merely because several navigator features use it.
|
|
173
|
-
- Generally reusable
|
|
174
|
-
|
|
175
|
-
|
|
194
|
+
- Generally reusable across repositories: it belongs in the canonical `@ankhorage/utility` topic
|
|
195
|
+
under the reuse-first rule above. Examples include generic string escaping or source-literal
|
|
196
|
+
serialization. Do not change semantics merely to reuse a similarly named function.
|
|
176
197
|
|
|
177
198
|
Separate the decisions for functions and types: reusable functions belong to Utility when general;
|
|
178
199
|
repo-local type groups belong to `src/types/`; repo-crossing types belong to Contracts. Respect
|
package/package.json
CHANGED