@orkestrel/scaffold 0.0.2 → 0.0.4
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.
- package/README.md +29 -15
- package/dist/bin/scaffold.js +1162 -1200
- package/dist/bin/scaffold.js.map +1 -1
- package/dist/host/AGENTS.md +124 -925
- package/dist/host/CLAUDE.md +335 -495
- package/dist/host/agents/skills/orkestrel-align-packages/SKILL.md +53 -0
- package/dist/host/agents/skills/orkestrel-align-packages/agents/openai.yaml +4 -0
- package/dist/host/agents/skills/orkestrel-align-packages/references/fleet.md +50 -0
- package/dist/host/agents/skills/orkestrel-align-packages/references/integration.md +56 -0
- package/dist/host/agents/skills/orkestrel-build-application/SKILL.md +64 -0
- package/dist/host/agents/skills/orkestrel-build-application/agents/openai.yaml +4 -0
- package/dist/host/agents/skills/orkestrel-build-application/references/application.md +129 -0
- package/dist/host/agents/skills/orkestrel-harden-package/SKILL.md +64 -0
- package/dist/host/agents/skills/orkestrel-harden-package/agents/openai.yaml +4 -0
- package/dist/host/agents/skills/orkestrel-harden-package/references/centralization.md +85 -0
- package/dist/host/agents/skills/orkestrel-harden-package/references/contract.md +57 -0
- package/dist/host/agents/skills/orkestrel-harden-package/references/hardening.md +93 -0
- package/dist/host/agents/skills/orkestrel-harden-package/references/research.md +61 -0
- package/dist/host/claude/agents/application.md +30 -0
- package/dist/host/claude/agents/builder.md +10 -7
- package/dist/host/claude/agents/checker.md +14 -8
- package/dist/host/claude/agents/codex.md +94 -0
- package/dist/host/claude/agents/grok.md +37 -34
- package/dist/host/claude/agents/implementer.md +40 -0
- package/dist/host/claude/agents/orkestrel.md +88 -223
- package/dist/host/claude/agents/planner.md +13 -34
- package/dist/host/claude/agents/reviewer.md +38 -24
- package/dist/host/claude/agents/verifier.md +14 -10
- package/dist/host/claude/rules/application.md +57 -0
- package/dist/host/claude/rules/architecture.md +180 -0
- package/dist/host/claude/rules/browser.md +28 -0
- package/dist/host/claude/rules/documentation.md +64 -0
- package/dist/host/claude/rules/names.md +209 -0
- package/dist/host/claude/rules/patterns.md +130 -0
- package/dist/host/claude/rules/quality.md +45 -0
- package/dist/host/claude/rules/styles.md +64 -0
- package/dist/host/claude/rules/tests.md +123 -0
- package/dist/host/claude/rules/typescript.md +78 -0
- package/dist/host/claude/rules/workspace.md +180 -0
- package/dist/host/claude/settings.json +112 -0
- package/dist/host/claude/skills/orkestrel-align-packages/SKILL.md +10 -0
- package/dist/host/claude/skills/orkestrel-build-application/SKILL.md +12 -0
- package/dist/host/claude/skills/orkestrel-harden-package/SKILL.md +10 -0
- package/dist/host/codex/agents/analyst.toml +15 -0
- package/dist/host/codex/agents/application.toml +25 -0
- package/dist/host/codex/agents/builder.toml +24 -0
- package/dist/host/codex/agents/checker.toml +15 -0
- package/dist/host/codex/agents/grok.toml +17 -0
- package/dist/host/codex/agents/implementer.toml +17 -0
- package/dist/host/codex/agents/opus.toml +25 -0
- package/dist/host/codex/agents/orkestrel.toml +16 -0
- package/dist/host/codex/agents/planner.toml +20 -0
- package/dist/host/codex/agents/reviewer.toml +18 -0
- package/dist/host/codex/agents/verifier.toml +14 -0
- package/dist/host/codex/config.toml +66 -0
- package/dist/host/cursor/mcp.json +12 -0
- package/dist/host/dotfiles/mcp.json +8 -0
- package/dist/host/dotfiles/oxlintrc.json +307 -1
- package/dist/host/guides/src/scaffold.md +2059 -2007
- package/dist/host/manifest.json +376 -137
- package/dist/host/scripts/codex.sh +49 -0
- package/dist/host/scripts/cursor.sh +33 -47
- package/dist/host/scripts/deps.sh +34 -16
- package/dist/host/scripts/ollama.sh +6 -149
- package/dist/host/tests/setupPolicy.ts +390 -0
- package/dist/src/core/index.cjs +6603 -1200
- package/dist/src/core/index.cjs.map +1 -1
- package/dist/src/core/index.d.cts +802 -267
- package/dist/src/core/index.d.ts +802 -267
- package/dist/src/core/index.js +6521 -1192
- package/dist/src/core/index.js.map +1 -1
- package/dist/src/server/index.cjs +3132 -593
- package/dist/src/server/index.cjs.map +1 -1
- package/dist/src/server/index.d.cts +643 -95
- package/dist/src/server/index.d.ts +643 -95
- package/dist/src/server/index.js +3054 -594
- package/dist/src/server/index.js.map +1 -1
- package/package.json +16 -12
- package/dist/host/claude/agents/composer.md +0 -64
- package/dist/host/claude/agents/researcher.md +0 -38
- package/dist/host/claude/agents/scout.md +0 -35
- package/dist/host/github/workflows/ci.yml +0 -64
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: orkestrel-align-packages
|
|
3
|
+
description: Audit and improve how two or more Orkestrel packages, or their core, server, browser, and app environments, fit together. Use for coordinated package-stack refactors, cross-package extraction, developer-ergonomics reviews, end-to-end or live integration testing, dependency and guide alignment, and fleet/package-manager campaigns. Preserve host-independent core boundaries, update dependents topologically, and use the package-hardening workflow for each implementation unit.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Align Orkestrel packages
|
|
7
|
+
|
|
8
|
+
## Load authority
|
|
9
|
+
|
|
10
|
+
Read the current authority in this order:
|
|
11
|
+
|
|
12
|
+
1. `AGENTS.md` and applicable `.claude/rules/*.md`.
|
|
13
|
+
2. The `integration.md` and `fleet.md` references selected below.
|
|
14
|
+
3. `CLAUDE.md` or `.codex/config.toml` for orchestration.
|
|
15
|
+
4. Relevant package guides, `guides/src/scaffold.md`, and the configured Orkestrel specialist.
|
|
16
|
+
|
|
17
|
+
Explicit user scope wins.
|
|
18
|
+
|
|
19
|
+
Use live manifests, lockfiles, installed declarations, guides, branches, and consumer code. Never trust remembered package versions, dependency ranges, or catalog entries.
|
|
20
|
+
|
|
21
|
+
Load [integration.md](references/integration.md) for cross-package or cross-environment ownership, ergonomics, extraction, and real round-trip tests.
|
|
22
|
+
|
|
23
|
+
Load [fleet.md](references/fleet.md) for version/range/guide drift, dependency blast radius, consumer-artifact validation, or campaign state.
|
|
24
|
+
|
|
25
|
+
Invoke `$orkestrel-harden-package` for each package implementation unit. This skill owns cross-package decisions; the hardening skill owns the complete work inside one package.
|
|
26
|
+
|
|
27
|
+
## Execute the campaign
|
|
28
|
+
|
|
29
|
+
1. **Create one registry.** Record the campaign goal, authoritative session, repositories, branches, dirty state, declared/resolved versions, dependency edges, guide state, write scope, and exclusions.
|
|
30
|
+
2. **Bound context.** Scout only packages and consumers relevant to the behavior. Use registry/canonical sources for the rest of the fleet.
|
|
31
|
+
3. **Trace the real flow.** Follow public types and one concrete consumer end to end. Identify where ergonomics break and which layer owns the reusable mechanism.
|
|
32
|
+
4. **Assign ownership.** Keep core host-independent. Keep server free of browser assumptions and browser free of Node assumptions. Keep product policy in applications.
|
|
33
|
+
5. **Judge downstream friction.** Treat consumer gymnastics as evidence, not automatic proof. Decide whether the consumer misused a coherent API or exposed a general upstream defect.
|
|
34
|
+
6. **Design in dependency order.** Update guides and types first in the lowest owning package, then update every affected consumer atomically. Do not add compatibility shims.
|
|
35
|
+
7. **Harden each unit.** Apply `$orkestrel-harden-package` to every touched package with the exact owned scope and acceptance criteria.
|
|
36
|
+
8. **Prove the round trip.** Put integration coverage at the highest package that can exercise the real composed behavior. Retain focused deterministic coverage in lower packages.
|
|
37
|
+
9. **Validate local changes safely.** When necessary, use built artifacts in an isolated consumer and prove the resolved graph. Restore temporary manifest/lockfile state.
|
|
38
|
+
10. **Verify topologically.** Run local gates for touched packages from dependencies to dependents and inspect relevant generated outputs.
|
|
39
|
+
11. **Review the campaign.** Require independent correctness and conformance review per implementation unit plus one cross-package architecture/ergonomics review.
|
|
40
|
+
|
|
41
|
+
## Accept the result
|
|
42
|
+
|
|
43
|
+
Completion requires:
|
|
44
|
+
|
|
45
|
+
- ownership and dependency direction remain coherent;
|
|
46
|
+
- the concrete consumer no longer needs unjustified gymnastics;
|
|
47
|
+
- every changed public contract, consumer, test, and guide is aligned;
|
|
48
|
+
- real round-trip behavior is proven at the correct layer;
|
|
49
|
+
- package versions/ranges/guides are reported from live evidence;
|
|
50
|
+
- every touched repository's requested local gates are green;
|
|
51
|
+
- no in-scope work is deferred.
|
|
52
|
+
|
|
53
|
+
Report the final package graph, ownership decisions, shipped behavior, exact verification, residual risk, and any user decision still required.
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
# Fleet alignment
|
|
2
|
+
|
|
3
|
+
## Verify live state
|
|
4
|
+
|
|
5
|
+
For every relevant repository, record:
|
|
6
|
+
|
|
7
|
+
- local package name/version;
|
|
8
|
+
- branch and relation to `origin/main`;
|
|
9
|
+
- dirty paths and owning session;
|
|
10
|
+
- declared and resolved `@orkestrel/*` dependencies, peers, and dev dependencies;
|
|
11
|
+
- vendored guide freshness;
|
|
12
|
+
- supported runtime and package environments;
|
|
13
|
+
- local gate/package state.
|
|
14
|
+
|
|
15
|
+
Use npm, git, manifests, lockfiles, installed packages, canonical guides, and current scaffold authority. Do not copy a package catalog or burned-version list into this skill.
|
|
16
|
+
|
|
17
|
+
For `0.0.x`, verify the actual range behavior rather than assuming ordinary caret semantics. Record exact intended ranges and resolved versions.
|
|
18
|
+
|
|
19
|
+
## Build the dependency plan
|
|
20
|
+
|
|
21
|
+
Produce:
|
|
22
|
+
|
|
23
|
+
1. the transitive blast radius grouped by dependency layer;
|
|
24
|
+
2. a table of each required range/guide/consumer change;
|
|
25
|
+
3. topological implementation and local-verification order;
|
|
26
|
+
4. explicit shared files and serial integration points;
|
|
27
|
+
5. per-repository acceptance criteria;
|
|
28
|
+
6. risks from dirty branches, incompatible runtimes, live-service requirements, or conflicting sessions.
|
|
29
|
+
|
|
30
|
+
Keep one authoritative session per package. Re-establish live state before acting because another session may have moved it.
|
|
31
|
+
|
|
32
|
+
## Validate local packages
|
|
33
|
+
|
|
34
|
+
When a dependent must verify a local package:
|
|
35
|
+
|
|
36
|
+
- build the dependency;
|
|
37
|
+
- consume its built artifact only in an isolated or explicitly authorized consumer;
|
|
38
|
+
- prove every relevant resolution points to the intended artifact;
|
|
39
|
+
- run the dependent's targeted then final local gates;
|
|
40
|
+
- restore temporary overrides, manifest edits, and lockfile state.
|
|
41
|
+
|
|
42
|
+
Do not treat an undeclared source-checkout import as consumer proof.
|
|
43
|
+
|
|
44
|
+
## Align guides and verification
|
|
45
|
+
|
|
46
|
+
Refresh dependency guides through the current scaffold workflow when the owning repository and scope permit it. Report drift rather than hand-editing a vendored guide whose canonical source lives elsewhere.
|
|
47
|
+
|
|
48
|
+
Run package-local verification from dependencies to dependents. A passing lower package does not prove its consumer; a passing consumer does not replace lower-package invariants.
|
|
49
|
+
|
|
50
|
+
Report the verified dependency order, guide state, and remaining campaign risks.
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
# Cross-package and environment integration
|
|
2
|
+
|
|
3
|
+
## Map ownership
|
|
4
|
+
|
|
5
|
+
Use this dependency model unless a package-specific guide narrows it:
|
|
6
|
+
|
|
7
|
+
| Surface | May depend on | Must not depend on |
|
|
8
|
+
| ------------- | ------------------------------------------------------------------- | -------------------------------------- |
|
|
9
|
+
| `src/core` | host-independent Orkestrel core packages | Node, DOM, browser/server environments |
|
|
10
|
+
| `src/server` | its core and server-capable dependencies | browser/app environments |
|
|
11
|
+
| `src/browser` | its core and browser-capable dependencies | Node/server/app environments |
|
|
12
|
+
| `app/core` | host-independent library/core and app/core logic | Node, DOM, app/server, app/browser |
|
|
13
|
+
| `app/server` | app/core plus core/server libraries | browser/app/browser |
|
|
14
|
+
| `app/browser` | app/core plus core/browser libraries and shared transport contracts | Node/app/server implementation |
|
|
15
|
+
|
|
16
|
+
Browser application code reaches server behavior through shared contracts and transports, not server implementation imports.
|
|
17
|
+
|
|
18
|
+
Framework packages own reusable mechanisms. Applications own workflows, policy, presentation, users, authorization decisions, and product-specific defaults.
|
|
19
|
+
|
|
20
|
+
## Use consumers as evidence
|
|
21
|
+
|
|
22
|
+
Read the concrete consumer flow first-hand:
|
|
23
|
+
|
|
24
|
+
1. Identify the desired use case.
|
|
25
|
+
2. Trace construction, types, options, calls, events/results, cleanup, and errors.
|
|
26
|
+
3. Record every adapter, cast, wrapper, duplicate schema, or ordering workaround.
|
|
27
|
+
4. Decide whether it reflects:
|
|
28
|
+
- consumer misuse or missing local composition;
|
|
29
|
+
- a documentation/ergonomics defect;
|
|
30
|
+
- a genuinely misplaced or incomplete upstream mechanism.
|
|
31
|
+
|
|
32
|
+
“Upstream never bends for downstream” is too rigid. Downstream friction may reveal an upstream defect. Fix the lowest package that owns the general mechanism, but never leak product policy upward.
|
|
33
|
+
|
|
34
|
+
## Extract across packages
|
|
35
|
+
|
|
36
|
+
When moving behavior:
|
|
37
|
+
|
|
38
|
+
- define the destination contract and guide first;
|
|
39
|
+
- keep storage/transport integrations pluggable where consumers choose them;
|
|
40
|
+
- move the real implementation, tests, and guide together;
|
|
41
|
+
- delete the source duplicate and update every consumer;
|
|
42
|
+
- use originating package imports; never re-export dependency symbols;
|
|
43
|
+
- validate the change without compatibility shims.
|
|
44
|
+
|
|
45
|
+
## Design round-trip tests
|
|
46
|
+
|
|
47
|
+
Place each proof at the highest useful layer:
|
|
48
|
+
|
|
49
|
+
- lower package: fast deterministic invariants and boundary behavior;
|
|
50
|
+
- adapter package: real protocol/storage/browser integration;
|
|
51
|
+
- highest consumer package: one composed ergonomic workflow;
|
|
52
|
+
- dedicated live-service package: real model/service behavior.
|
|
53
|
+
|
|
54
|
+
Use the actual packages and transports. Use temporary resources or protocol-faithful fixture servers for deterministic network boundaries. Use the real external service when its behavior is the claim. Never simulate an owned package with a mock or fake.
|
|
55
|
+
|
|
56
|
+
Test both successful composition and contract disagreement: invalid options, unavailable capability, partial failure, abort/cleanup, version mismatch, and lifecycle ordering where applicable.
|
|
@@ -0,0 +1,64 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: orkestrel-build-application
|
|
3
|
+
description: Design, scaffold, extend, or harden Orkestrel `app/core`, `app/browser`, and `app/server` environments. Use for app-only or mixed src/app workspaces, app environment isolation, Vue browser entries, Node server entries, app aliases/configs/scripts/tests, cross-environment contracts, and application guide parity.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Build an Orkestrel application
|
|
7
|
+
|
|
8
|
+
Read `AGENTS.md`, `.claude/rules/application.md`, `.claude/rules/workspace.md`,
|
|
9
|
+
`.claude/rules/architecture.md`, `.claude/rules/documentation.md`, and every other rule
|
|
10
|
+
selected by the files in scope. Then read
|
|
11
|
+
[`references/application.md`](references/application.md) completely.
|
|
12
|
+
|
|
13
|
+
## Workflow
|
|
14
|
+
|
|
15
|
+
1. Inventory existing `src`, `app`, `configs`, tests, manifest scripts, aliases,
|
|
16
|
+
and guide rows. Treat current code as evidence, not policy.
|
|
17
|
+
2. Select only required environments. `--src` selects published src environments and
|
|
18
|
+
`--app` selects private app environments; the two selections are independent,
|
|
19
|
+
at least one is required, and there is no `--surfaces` synonym. Each side offers
|
|
20
|
+
`core`, `browser`, and `server`. Browser and server may depend on their core, core
|
|
21
|
+
depends on neither host implementation, and browser/server remain disjoint.
|
|
22
|
+
3. Define or refine public contracts in each environment's `types.ts` before
|
|
23
|
+
implementation. Inspect exact installed `@orkestrel/*` capabilities before
|
|
24
|
+
writing boundary code, and reuse a primitive whose semantics match.
|
|
25
|
+
4. Add aliases in root TypeScript configuration and derive Vite aliases from
|
|
26
|
+
them. Keep `configs/app` wrappers thin.
|
|
27
|
+
5. Implement complete entries, `export *`-only barrels, centralized `types.ts` /
|
|
28
|
+
`constants.ts` / `helpers.ts` and their sibling kind files, dedicated one-class
|
|
29
|
+
implementation files, environment parsing, lifecycle, builds, and scripts.
|
|
30
|
+
App-only manifests must be `private: true`; mixed manifests publish only
|
|
31
|
+
`dist/src` and never expose `dist/app`.
|
|
32
|
+
6. Keep boundary enforcement inside the configured toolchain, each layer owning what
|
|
33
|
+
it can express: Oxlint `no-restricted-imports` for literal-string declared package,
|
|
34
|
+
alias, and conventional relative import direction; Oxfmt for formatting;
|
|
35
|
+
`tests/setupPolicy.ts` as the narrow TypeScript compiler-API pass over computed and
|
|
36
|
+
template-literal specifiers, declaration placement, and the barrel law; scoped
|
|
37
|
+
TypeScript projects for host-global isolation; and Vite's real browser/server
|
|
38
|
+
builds and environment-boundary plugin for Vue, CSS, assets, workers, runtime
|
|
39
|
+
resolution, and physical workspace containment, using Vite's Oxc AST for
|
|
40
|
+
TypeScript/JavaScript, the official Vue SFC compiler for `.vue` blocks, Vite's
|
|
41
|
+
HTML parser callbacks, and Vite's bundled Lightning CSS dependency analyzer.
|
|
42
|
+
Exercise the combined configuration through
|
|
43
|
+
fresh generated-consumer lint, typecheck, build, and integration tests. Add no
|
|
44
|
+
standalone boundary script and no second general-purpose parser or source-language
|
|
45
|
+
analyzer duplicating those layers. Keep browser-only runtime tooling
|
|
46
|
+
development-only and require explicit authorization before adding a Sass compiler.
|
|
47
|
+
7. Add real app/core Node tests, app/browser Playwright-backed Chromium tests,
|
|
48
|
+
app/server loopback and child-process tests, and cross-environment integration.
|
|
49
|
+
Exercise repeated lifecycle, malformed environment values, protocol failures,
|
|
50
|
+
concurrency, hostile connections, and cleanup. A signal-owning server runner must
|
|
51
|
+
expose idempotent explicit stop so normal shutdown releases every installed process
|
|
52
|
+
listener; stale asynchronous failures cannot mutate a newer generation, and
|
|
53
|
+
convenience starters return the runner rather than hiding that cleanup contract.
|
|
54
|
+
Keep the runner class alone in `ApplicationServerRunner.ts` and its convenience
|
|
55
|
+
starter in centralized `factories.ts`.
|
|
56
|
+
8. Update the guide, examples, manifest index, and parity specifiers for every
|
|
57
|
+
app export and behavioral method.
|
|
58
|
+
9. Run source cleanup, test cleanup, one independent design audit and one
|
|
59
|
+
independent objective audit, a mechanical conformance pass, and the
|
|
60
|
+
repository gates in their required order.
|
|
61
|
+
|
|
62
|
+
Do not add showcase, authentication, persistence, proxy, styling-system, or
|
|
63
|
+
product policy unless the request requires it. Do not leave placeholders,
|
|
64
|
+
compatibility shims, empty setup files, or deferred app behavior.
|
|
@@ -0,0 +1,129 @@
|
|
|
1
|
+
# Application architecture reference
|
|
2
|
+
|
|
3
|
+
## Environment selection
|
|
4
|
+
|
|
5
|
+
Support application-only, source-only, and mixed workspaces.
|
|
6
|
+
The CLI uses `--src core,browser,server` for published src environments and
|
|
7
|
+
`--app core,browser,server` for private app environments. At least one selector
|
|
8
|
+
is required in non-interactive creation; `--surfaces` is not part of the
|
|
9
|
+
vocabulary.
|
|
10
|
+
|
|
11
|
+
| Selection | Contract |
|
|
12
|
+
| ----------- | ------------------------------------------------------ |
|
|
13
|
+
| app/core | Host-independent contracts and composition |
|
|
14
|
+
| app/browser | Vue browser runtime and real-browser tests |
|
|
15
|
+
| app/server | Node runtime, executable CJS build, and loopback tests |
|
|
16
|
+
|
|
17
|
+
Core-only, browser-only, and server-only are valid. A browser+server pair must
|
|
18
|
+
include app/core so shared transport contracts have one host-independent owner.
|
|
19
|
+
|
|
20
|
+
## Dependency direction
|
|
21
|
+
|
|
22
|
+
- app/core imports no DOM, Node, app/browser, or app/server implementation.
|
|
23
|
+
- app/browser may import app/core and published browser/core packages.
|
|
24
|
+
- app/server may import app/core and published server/core packages.
|
|
25
|
+
- Published src environments never import private app modules. Src core is
|
|
26
|
+
host-independent; src browser/server may import src core and remain
|
|
27
|
+
mutually disjoint.
|
|
28
|
+
- Apply the same direction to cross-package `@orkestrel/<package>/browser` and
|
|
29
|
+
`/server` exports; a package's bare export is its core API.
|
|
30
|
+
- Browser code reaches server behavior through app/core contracts and a
|
|
31
|
+
transport boundary, never by importing app/server.
|
|
32
|
+
- Every environment barrel contains `export *` declarations only. A star-export
|
|
33
|
+
collision is a design failure to be renamed at its owner, never hidden behind
|
|
34
|
+
a selective barrel row.
|
|
35
|
+
- Types, constants, helpers, validators, parsers, and factories live in their
|
|
36
|
+
centralized kind files; an implementation file holds one class plus imports.
|
|
37
|
+
`ApplicationServerRunner` lives alone in `ApplicationServerRunner.ts` and
|
|
38
|
+
`startApplicationServer` in `factories.ts`; `main.ts` owns no reusable
|
|
39
|
+
declarations.
|
|
40
|
+
- Enforcement is layered, and each layer owns exactly what it can express:
|
|
41
|
+
- `.oxlintrc.json` `no-restricted-imports` owns **literal-string** declared
|
|
42
|
+
package, alias, and conventional relative imports, in both directions.
|
|
43
|
+
`.oxfmtrc.json` owns formatting. Neither replaces the other, and neither
|
|
44
|
+
replaces typechecking.
|
|
45
|
+
- `tests/setupPolicy.ts` owns what Oxlint cannot represent: computed and
|
|
46
|
+
template-literal import specifiers, declaration placement, and the
|
|
47
|
+
export-star barrel law. It is a deliberately narrow TypeScript-compiler pass
|
|
48
|
+
over the repository's own coding laws — not a general-purpose analyzer, and
|
|
49
|
+
not a second linter.
|
|
50
|
+
- Scoped TypeScript projects remove Node/DOM globals from the wrong
|
|
51
|
+
environment.
|
|
52
|
+
- Vite's real browser/server builds resolve Vue, assets, CSS, workers, and
|
|
53
|
+
runtime module graphs, and its generated environment-boundary plugin checks
|
|
54
|
+
dependency direction and physical workspace containment on the actual graph.
|
|
55
|
+
Vite's parsed HTML asset callbacks reject forced inlining before any direct
|
|
56
|
+
asset read; non-inlined output assets are audited by physical source path.
|
|
57
|
+
- Generated-consumer lint, typecheck, build, and integration tests prove the
|
|
58
|
+
combined configuration.
|
|
59
|
+
- Do not add a second general-purpose parser, source-language analyzer, or
|
|
60
|
+
boundary script that duplicates a layer above. Use the toolchain's own
|
|
61
|
+
facilities instead: Vite's Oxc/Rolldown AST for TypeScript and JavaScript
|
|
62
|
+
asset references, the official Vue SFC compiler for `.vue` blocks, Vite's
|
|
63
|
+
HTML parser callbacks, its bundled Lightning CSS dependency analyzer, and the
|
|
64
|
+
TypeScript compiler API for the narrow coding-law pass.
|
|
65
|
+
- Include `.ts`, `.tsx`, `.mts`, and `.cts` in every scoped TypeScript check.
|
|
66
|
+
Vue SFCs belong only to app/browser. CSS is the generated browser style
|
|
67
|
+
format; SCSS requires an explicitly authorized Sass compiler dependency.
|
|
68
|
+
|
|
69
|
+
## Entries and configuration
|
|
70
|
+
|
|
71
|
+
- Every selected app environment has an `index.ts` barrel.
|
|
72
|
+
- app/browser executes from `main.ts` through `index.html`.
|
|
73
|
+
- app/server centralizes process signals in an explicitly stoppable runner,
|
|
74
|
+
returns that runner from convenience startup so cleanup is never hidden, and
|
|
75
|
+
executes it from a declaration-free `main.ts`; its bundle is
|
|
76
|
+
`dist/app/server/main.cjs`, with only `node:*` external.
|
|
77
|
+
- app/core is check/test-only.
|
|
78
|
+
- Root `tsconfig.json` owns `@app/*` aliases.
|
|
79
|
+
- Root `vite.config.ts` owns shared config and Vitest projects.
|
|
80
|
+
- `configs/app` contains thin target wrappers and scoped tsconfigs.
|
|
81
|
+
- app/browser uses `vue-tsc`; other app environments use `tsc`.
|
|
82
|
+
|
|
83
|
+
## Manifest policy
|
|
84
|
+
|
|
85
|
+
- App-only: unscoped name, `private: true`, no package `main`, `module`,
|
|
86
|
+
`types`, `exports`, or public `publishConfig`.
|
|
87
|
+
- Mixed: normal published source entries; package files include `dist/src` and
|
|
88
|
+
exclude `dist/app`.
|
|
89
|
+
- Add Vue only to development tooling when app/browser is selected; mixed
|
|
90
|
+
publication must not expose an app-only Vue runtime dependency.
|
|
91
|
+
- Add no product-specific dependencies or optional showcase tooling by default.
|
|
92
|
+
|
|
93
|
+
## Boundaries and tests
|
|
94
|
+
|
|
95
|
+
- Default server host is loopback.
|
|
96
|
+
- Parse the options container and host/port leaves before mutation; reject
|
|
97
|
+
wrong-shaped containers, empty hosts, and non-integer, negative, or
|
|
98
|
+
out-of-range ports with a coded error and guard.
|
|
99
|
+
- Lifecycle transitions serialize in call order, ephemeral restarts re-request
|
|
100
|
+
port zero, server stop closes hostile active connections deterministically,
|
|
101
|
+
and runner stop idempotently releases its SIGINT/SIGTERM listeners. Runner
|
|
102
|
+
generations isolate asynchronous failures so an older transition cannot
|
|
103
|
+
release a newer run's listeners.
|
|
104
|
+
- Real child-process tests prove executable readiness, collision exit, signal
|
|
105
|
+
termination, and port release. On Windows, `ChildProcess.kill('SIGTERM')`
|
|
106
|
+
reports OS termination by signal; POSIX delivery exercises the runner's
|
|
107
|
+
graceful signal listener and exits zero.
|
|
108
|
+
- Browser tests use Playwright-backed Vitest Browser Mode and real DOM. A
|
|
109
|
+
browser-capability check probes the installed executable directly with
|
|
110
|
+
`existsSync(chromium.executablePath())`; there is no channel or environment
|
|
111
|
+
guessing.
|
|
112
|
+
- Server tests bind port zero on loopback and use real fetch requests.
|
|
113
|
+
- Capability-dependent tests probe the actual capability and scope any skip.
|
|
114
|
+
- The generated browser application disables the public directory so an
|
|
115
|
+
unmanaged file copy cannot bypass the module graph or its boundary checks.
|
|
116
|
+
- Generated CI runs the gates on the declared minimum Node release and on the
|
|
117
|
+
current major.
|
|
118
|
+
- Guide parity walks existing `src` and/or `app` roots and maps every selected
|
|
119
|
+
`@src/*` / `@app/*` alias.
|
|
120
|
+
|
|
121
|
+
## Cleanup before gates
|
|
122
|
+
|
|
123
|
+
- Source: no stray or misplaced declarations, non-exported centralized
|
|
124
|
+
declarations, nested function declarations, duplicate implementations,
|
|
125
|
+
superfluous wrappers, compatibility aliases, or stale imports and barrel rows.
|
|
126
|
+
- Tests: no unused or duplicated helpers, empty setup files, placeholder suites,
|
|
127
|
+
current-scope `.todo` / `.skip`, or assertions that cannot fail.
|
|
128
|
+
- Text: UTF-8 only; scan generated or migrated edits for replacement characters,
|
|
129
|
+
mojibake, and stray control characters.
|
|
@@ -0,0 +1,64 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: orkestrel-harden-package
|
|
3
|
+
description: Research, audit, refactor, implement, centralize, test, document, and locally verify an individual Orkestrel TypeScript package to enterprise-grade production readiness under the repository's current AGENTS.md. Use when asked to fill missing or deferred capabilities, compare upstream or legacy implementations, salvage prior art, centralize source or test declarations, eliminate nested functions or superfluous wrappers, maximize declared @orkestrel dependencies—especially @orkestrel/contract—or add rigorous real-implementation and live-service tests. Select only the phases required by a narrow request; run the full workflow for production readiness or comprehensive hardening.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Harden an Orkestrel package
|
|
7
|
+
|
|
8
|
+
## Load authority
|
|
9
|
+
|
|
10
|
+
Read the current files in this order:
|
|
11
|
+
|
|
12
|
+
1. `AGENTS.md`.
|
|
13
|
+
2. Every applicable `.claude/rules/*.md`.
|
|
14
|
+
3. Select the work lane below and read every reference that lane requires.
|
|
15
|
+
4. `guides/README.md`, the governing package/domain guide, and `ROADMAP.md` when present.
|
|
16
|
+
5. The authoritative `*/types.ts`, public barrels, `package.json`, build/test configuration, and decision-bearing implementation files.
|
|
17
|
+
|
|
18
|
+
Treat the current user instruction as authoritative. Treat repository rules as the coding contract and this skill as the workflow. Preserve dirty and user-owned work.
|
|
19
|
+
|
|
20
|
+
The decision owner must read the governing types and every implementation file the user names directly. Delegate bulk reconnaissance or supporting research, not the final design decision.
|
|
21
|
+
|
|
22
|
+
## Select the work lane
|
|
23
|
+
|
|
24
|
+
Choose the smallest lane that fully satisfies the request:
|
|
25
|
+
|
|
26
|
+
- **Structural:** centralization, nested-function removal, wrapper cleanup, or test-infrastructure consolidation.
|
|
27
|
+
- **Capability:** research and implement named missing behavior or upstream parity.
|
|
28
|
+
- **Hardening:** perform the complete production-readiness workflow.
|
|
29
|
+
|
|
30
|
+
A narrow structural request does not authorize unrelated API redesign. A hardening request does authorize fixing every verified in-scope defect and completing every in-scope deferred capability.
|
|
31
|
+
|
|
32
|
+
Load [research.md](references/research.md) for upstream comparisons, legacy/`old/` material, or capability discovery.
|
|
33
|
+
|
|
34
|
+
Load [contract.md](references/contract.md) whenever the package declares `@orkestrel/contract`, the user requests contract adoption, or local code overlaps validation, parsing, outcomes, safe exception capture, schemas, or contract generation.
|
|
35
|
+
|
|
36
|
+
Load [centralization.md](references/centralization.md) for every structural lane and as a mandatory cleanup pass after capability or hardening work.
|
|
37
|
+
|
|
38
|
+
Load [hardening.md](references/hardening.md) for the hardening lane and for any request involving concurrency, lifecycle pressure, security boundaries, real services/models, test discovery, or package inspection.
|
|
39
|
+
|
|
40
|
+
## Execute the workflow
|
|
41
|
+
|
|
42
|
+
1. **Bound the campaign.** Record requested outcomes, in-scope environments/domains, explicit exclusions, supported hosts, dirty files, and evidence needed for acceptance.
|
|
43
|
+
2. **Map before editing.** Trace public types, implementations, callers, tests, guides, exports, runtime boundaries, installed Orkestrel dependencies, and applicable legacy/upstream references.
|
|
44
|
+
3. **Establish the intended contract.** Build a capability/defect matrix. Separate verified fact from inference. Mark each row implement, repair, retain, or exclude with a reason.
|
|
45
|
+
4. **Design types first.** Update guide/spec intent and `*/types.ts` before implementation. Preserve dependency direction, single-word entity APIs, and mechanism-over-policy boundaries. Do not retain compatibility shims.
|
|
46
|
+
5. **Implement completely.** Finish every in-scope branch. Reuse exact installed Orkestrel primitives when their semantics match. Never hide incomplete behavior behind a TODO, skip, empty branch, or success-shaped placeholder.
|
|
47
|
+
6. **Consolidate.** Run the complete centralization and wrapper sweep. Update all call sites to the real symbol rather than leaving aliases or 1:1 delegates.
|
|
48
|
+
7. **Challenge seams.** Add deterministic tests for invariants, boundaries, failures, lifecycle, cleanup, cancellation, concurrency, hostile input, and resource pressure as applicable. Use real implementations and protocol-faithful fixtures. Never use mocks or fakes.
|
|
49
|
+
8. **Use live services deliberately.** Put real external services/models in their dedicated project, require readiness, and make each request minimally sufficient, robust, and behaviorally meaningful.
|
|
50
|
+
9. **Document the final behavior.** Update the governing guide, examples, method tables, limitations, and parity coverage. Document architectural limits honestly.
|
|
51
|
+
10. **Audit completion.** Inspect test discovery, `.todo`/`.skip`/conditional skip use, source/test helper duplication, exports, environment isolation, unexpected text corruption, and the entire diff.
|
|
52
|
+
11. **Verify.** Run the repository-prescribed gates in order and inspect the generated outputs relevant to the request.
|
|
53
|
+
12. **Review independently.** When orchestration is available, require a design-fit reviewer, an objective correctness/constraints analyst, and a mechanical checker; add an adversarial pass for security, concurrency, destructive paths, or external input. Resolve every required finding, then rerun affected verification.
|
|
54
|
+
|
|
55
|
+
## Accept the result
|
|
56
|
+
|
|
57
|
+
Do not accept “mostly complete,” “tests pass” without adequacy review, or a builder's self-report. Completion requires:
|
|
58
|
+
|
|
59
|
+
- all requested capabilities implemented or explicitly proven out of scope;
|
|
60
|
+
- public contract, implementation, tests, guides, and generated outputs aligned;
|
|
61
|
+
- no unresolved centralization, wrapper, dependency-reuse, test-discovery, lifecycle, security, or text-integrity finding;
|
|
62
|
+
- exact command evidence for every final gate.
|
|
63
|
+
|
|
64
|
+
Report what changed, what evidence proves it, exact test/gate results, and any genuine residual risk. Do not call an in-scope omission “future work.”
|
|
@@ -0,0 +1,85 @@
|
|
|
1
|
+
# Centralization and simplification
|
|
2
|
+
|
|
3
|
+
## Inventory declarations
|
|
4
|
+
|
|
5
|
+
Inspect every touched implementation and centralized file, then sweep the full affected environments.
|
|
6
|
+
|
|
7
|
+
For implementation files, inventory:
|
|
8
|
+
|
|
9
|
+
- interfaces and type aliases;
|
|
10
|
+
- module constants and data;
|
|
11
|
+
- free functions, guards, parsers, factories, and schemas;
|
|
12
|
+
- function declarations or assignments inside functions/methods;
|
|
13
|
+
- multiple classes;
|
|
14
|
+
- imports or exports left behind after moves.
|
|
15
|
+
|
|
16
|
+
Implementation files contain imports and one class. The rare runtime-self-contained entrypoint exception must be literally required for execution and must explain why sibling imports cannot work.
|
|
17
|
+
|
|
18
|
+
For centralized files, inventory every module declaration. Each declaration must:
|
|
19
|
+
|
|
20
|
+
- match that file's kind;
|
|
21
|
+
- be exported;
|
|
22
|
+
- be reachable from the sole public barrel when public by repository law;
|
|
23
|
+
- have direct behavioral coverage when it contains logic.
|
|
24
|
+
|
|
25
|
+
Promote a declaration to an environment root only when multiple modules consume it. Otherwise keep it in the owning module's centralized file.
|
|
26
|
+
|
|
27
|
+
## Apply the leaf test
|
|
28
|
+
|
|
29
|
+
Classify each function:
|
|
30
|
+
|
|
31
|
+
1. Instance state or sibling-method access: class method.
|
|
32
|
+
2. Pure, self-contained computation: exported centralized helper/parser/compiler/etc.
|
|
33
|
+
3. Defining recursive/compositional engine spine: class method after extracting its pure leaves.
|
|
34
|
+
4. Trivial, genuinely one-use expression: inline it.
|
|
35
|
+
|
|
36
|
+
Never move logic into a nested function to evade centralization. Anonymous callbacks passed directly to another operation remain callbacks, not hidden helper declarations.
|
|
37
|
+
|
|
38
|
+
## Remove superfluous wrappers
|
|
39
|
+
|
|
40
|
+
Search callers and callees for:
|
|
41
|
+
|
|
42
|
+
- one-line helper delegates;
|
|
43
|
+
- pass-through factories;
|
|
44
|
+
- getters that merely rename another public getter;
|
|
45
|
+
- duplicate guards/parsers already supplied by a declared dependency;
|
|
46
|
+
- compatibility aliases and re-exports;
|
|
47
|
+
- functions whose only purpose is avoiding a downstream rename.
|
|
48
|
+
|
|
49
|
+
A wrapper survives only if it owns a boundary, invariant, composition, translation, lifecycle, or materially narrower contract. Otherwise use or rename the real symbol and update every consumer.
|
|
50
|
+
|
|
51
|
+
Do not hollow a class into public methods that each forward to one helper. Keep meaningful orchestration on the entity and export only pure leaves.
|
|
52
|
+
|
|
53
|
+
## Consolidate tests
|
|
54
|
+
|
|
55
|
+
Sweep test files for repeated or reusable:
|
|
56
|
+
|
|
57
|
+
- input and result records;
|
|
58
|
+
- builders and factories;
|
|
59
|
+
- recorders and event capture;
|
|
60
|
+
- wait/readiness helpers;
|
|
61
|
+
- temporary workspace or fixture-server setup;
|
|
62
|
+
- browser/DOM builders and event factories;
|
|
63
|
+
- service request builders and response assertions.
|
|
64
|
+
|
|
65
|
+
Move host-independent helpers to `tests/setup.ts`; Node helpers to `tests/setupServer.ts`; browser helpers to `tests/setupBrowser.ts`; styles helpers to `tests/setupStyles.ts`; and live-service helpers to that project's dedicated setup.
|
|
66
|
+
|
|
67
|
+
Use customizable factories and inert stubs for data shapes. A scripted boundary stub may implement the real interface/protocol minimally to drive the system under test, but must not reproduce project-owned behavior or replace the integration being claimed. Otherwise use the real implementation, a temporary resource, a protocol-faithful fixture server, or the real external service.
|
|
68
|
+
|
|
69
|
+
Prefer recorders over spies. Do not use mocks or fakes.
|
|
70
|
+
|
|
71
|
+
Add focused tests for every exported function extracted from production code. Do not create isolated tests for declaration-only types, constants, barrels, or error definitions.
|
|
72
|
+
|
|
73
|
+
## Run the cleanup sweep
|
|
74
|
+
|
|
75
|
+
Before acceptance, prove:
|
|
76
|
+
|
|
77
|
+
- no stray declarations remain in implementation files;
|
|
78
|
+
- no non-exported or wrong-kind declaration remains in centralized files;
|
|
79
|
+
- no prohibited nested function declaration/assignment remains;
|
|
80
|
+
- no duplicate or rename-only wrapper remains;
|
|
81
|
+
- every move updated imports, barrels, guides, and tests;
|
|
82
|
+
- test helpers are consolidated without over-generalizing one-off setup;
|
|
83
|
+
- files are valid UTF-8 and contain no replacement characters, mojibake, unintended control characters, or accidental trailing debris.
|
|
84
|
+
|
|
85
|
+
Review the complete diff after formatting. Formatting cannot substitute for the structural sweep.
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# Adopt `@orkestrel/contract`
|
|
2
|
+
|
|
3
|
+
## Inspect the exact installed package
|
|
4
|
+
|
|
5
|
+
Never work from a remembered contract version or copied API list. Read:
|
|
6
|
+
|
|
7
|
+
1. `package.json` and the lockfile for the declared and resolved versions.
|
|
8
|
+
2. The vendored `guides/src/contract.md` when present.
|
|
9
|
+
3. The installed package's declaration file and exports.
|
|
10
|
+
4. Relevant package source or current canonical guide when semantics remain unclear.
|
|
11
|
+
|
|
12
|
+
Do not add `@orkestrel/contract` unless the user authorizes a dependency change. When it is already declared, use it to its full semantically appropriate extent.
|
|
13
|
+
|
|
14
|
+
## Build an overlap matrix
|
|
15
|
+
|
|
16
|
+
Inventory local code involving:
|
|
17
|
+
|
|
18
|
+
- primitive, structural, instance, collection, and total guards;
|
|
19
|
+
- guard combinators and refinements;
|
|
20
|
+
- coercing parsers and field readers;
|
|
21
|
+
- JSON parsing and narrowing;
|
|
22
|
+
- `Result`, success/failure outcomes, and safe exception capture;
|
|
23
|
+
- contract shapes, compiled guards/parsers/schemas/generators/reporters;
|
|
24
|
+
- finite/integer checks, error narrowing, and hostile-boundary containment.
|
|
25
|
+
|
|
26
|
+
For each local symbol, record:
|
|
27
|
+
|
|
28
|
+
| Local symbol | Contract candidate | Same semantics? | Difference | Decision | Required tests |
|
|
29
|
+
| ------------ | ------------------ | --------------- | ---------- | -------- | -------------- |
|
|
30
|
+
|
|
31
|
+
Replace only when semantics match or the current contract primitive is intentionally better for the desired API. A similar name is not proof.
|
|
32
|
+
|
|
33
|
+
## Refactor without wrappers
|
|
34
|
+
|
|
35
|
+
- Import the originating contract symbol directly when it already expresses the required operation.
|
|
36
|
+
- Update downstream call sites atomically.
|
|
37
|
+
- Delete rename-only, pass-through, and compatibility wrappers.
|
|
38
|
+
- Keep a local helper only when it adds a real invariant, composition, projection, domain translation, or boundary.
|
|
39
|
+
- Do not re-export contract symbols from another package's barrel.
|
|
40
|
+
- Prefer one compiled contract over independently maintained guard/parser/schema logic when the package genuinely needs those outputs.
|
|
41
|
+
- Prefer contract outcomes and safe attempt boundaries over repeated ad hoc `try`/`catch` shapes when their failure semantics match.
|
|
42
|
+
|
|
43
|
+
Do not force contract abstractions into plain control flow where they obscure behavior or change the error contract.
|
|
44
|
+
|
|
45
|
+
## Prove strictness and soundness
|
|
46
|
+
|
|
47
|
+
Test every adopted boundary for relevant invariants:
|
|
48
|
+
|
|
49
|
+
- guards are total for adversarial values and hostile prototypes;
|
|
50
|
+
- parsed values satisfy the paired guard;
|
|
51
|
+
- guard-valid values retain identity when promised;
|
|
52
|
+
- invalid or ambiguous values fail in the documented form;
|
|
53
|
+
- caught non-`Error` throws normalize as documented;
|
|
54
|
+
- compiled schema, parser, guard, generator, and reporter stay aligned when used;
|
|
55
|
+
- finite, integer, `NaN`, infinities, signed zero, cycles, depth, and cross-realm behavior are covered where applicable.
|
|
56
|
+
|
|
57
|
+
Run the centralization sweep after replacement so obsolete local types, helpers, constants, and tests do not remain.
|