@codemcp/ade 0.5.0 → 0.6.0
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/.beads/issues.jsonl +14 -0
- package/.beads/last-touched +1 -1
- package/.vibe/beads-state-ade-main-iazal7.json +29 -0
- package/.vibe/development-plan-extensibility.md +169 -0
- package/ade.extensions.mjs +66 -0
- package/docs/adr/0002-extension-file-type-safety.md +97 -0
- package/docs/guide/extensions.md +187 -0
- package/package.json +3 -2
- package/packages/cli/dist/index.js +99 -15
- package/packages/cli/package.json +4 -2
- package/packages/cli/src/commands/extensions.integration.spec.ts +122 -0
- package/packages/cli/src/commands/install.spec.ts +21 -1
- package/packages/cli/src/commands/install.ts +10 -5
- package/packages/cli/src/commands/setup.ts +8 -4
- package/packages/cli/src/extensions.spec.ts +128 -0
- package/packages/cli/src/extensions.ts +71 -0
- package/packages/cli/src/index.ts +10 -5
- package/packages/core/package.json +3 -2
- package/packages/core/src/catalog/index.ts +38 -1
- package/packages/core/src/extensions.spec.ts +169 -0
- package/packages/core/src/index.ts +3 -1
- package/packages/core/src/types.ts +71 -0
- package/packages/harnesses/package.json +1 -1
- package/packages/harnesses/src/index.spec.ts +48 -1
- package/packages/harnesses/src/index.ts +10 -0
- package/pnpm-workspace.yaml +2 -0
- /package/docs/{adrs → adr}/0001-tui-framework-selection.md +0 -0
package/.beads/issues.jsonl
CHANGED
|
@@ -60,3 +60,17 @@
|
|
|
60
60
|
{"id":"ade-5.1","title":"Explore","description":"Understand the problem, analyze existing patterns, and design your approach. Consider the scope and impact of the change. **STEP 1: Analyze Requirements** - If exists: Use it to understand the required changes - Otherwise: Document requirements in your task management system **STEP 2: Review Design Approach** - If exists: Respect the design approach documented in - Otherwise: Design your approach based on the problem analysis **STEP 3: Document Decisions** - Document your analysis and design decisions - Create tasks to guide implementation - Focus on analysis and design only - do not write any code yet","status":"open","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T11:33:13.459272+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T11:33:13.459272+01:00","dependencies":[{"issue_id":"ade-5.1","depends_on_id":"ade-5","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]}
|
|
61
61
|
{"id":"ade-5.2","title":"Implement","description":"Write clean, focused code for the minor enhancement, test your changes, and prepare for commit. **STEP 1: Review Design and Requirements** - If exists: Follow your design from - Otherwise: Elaborate design options and present them to the user - If exists: Ensure the relevant requirements from are met - Otherwise: Ensure existing requirements are met based on your task context **STEP 2: Implement Changes** - Write clean, focused code for the minor enhancement - Test your changes to ensure they work correctly and don't break existing functionality **STEP 3: Prepare for Finalization** - Update task progress as needed - Prepare documentation and commit when ready","status":"open","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T11:33:13.597501+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T11:33:13.597501+01:00","dependencies":[{"issue_id":"ade-5.2","depends_on_id":"ade-5","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-5.2","depends_on_id":"ade-5.1","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]}
|
|
62
62
|
{"id":"ade-5.3","title":"Finalize","description":"Ensure code quality and documentation accuracy through systematic cleanup and review. **STEP 1: Code Cleanup** Systematically clean up development artifacts: - **Remove Debug Output**: Search for and remove all temporary debug output statements used during development. Look for language-specific debug output methods (console logging, print statements, debug output functions). Remove any debugging statements that were added for development purposes. - **Review TODO/FIXME Comments**: - Address each TODO/FIXME comment by either implementing the solution or documenting why it's deferred - Remove completed TODOs - Convert remaining TODOs to proper issue tracking if needed - **Remove Debugging Code Blocks**: - Remove temporary debugging code, test code blocks, and commented-out code - Clean up any experimental code that's no longer needed - Ensure proper error handling replaces temporary debug logging **STEP 2: Documentation Review** Review and update documentation to reflect final implementation: - **Update Long-Term Memory Documents**: Based on what was actually implemented: - If exists: Update if requirements changed during development - If exists: Update if design details were refined or changed - **Compare Against Implementation**: Review documentation against actual implemented functionality - **Update Changed Sections**: Only modify documentation sections that have functional changes - **Remove Development Progress**: Remove references to development iterations, progress notes, and temporary decisions - **Focus on Final State**: Ensure documentation describes the final implemented state, not the development process - **Ask User to Review Document Updates** **STEP 3: Final Validation** - Run existing tests to ensure cleanup didn't break functionality - Verify documentation accuracy with a final review - Ensure minor enhancement is ready for delivery - Update task progress and mark completed work as you finalize the minor enhancement","status":"open","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T11:33:13.733496+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T11:33:13.733496+01:00","dependencies":[{"issue_id":"ade-5.3","depends_on_id":"ade-5","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-5.3","depends_on_id":"ade-5.2","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]}
|
|
63
|
+
{"id":"ade-6","title":"ade: epcc (development-plan.md)","description":"Responsible vibe engineering session using epcc workflow for ade","status":"closed","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T16:48:54.346525+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T20:46:05.46088+01:00","closed_at":"2026-03-19T20:46:05.46088+01:00","close_reason":"Closed"}
|
|
64
|
+
{"id":"ade-6.1","title":"Explore","description":"Research the codebase to understand existing patterns and gather context about the problem space. - If uncertain about conventions or rules, ask the user about them - Read relevant files and documentation - If exists: Understand and document requirements there - Otherwise: Document requirements in your task management system Focus on understanding without writing code yet. Document your findings and create tasks as needed.","status":"closed","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T16:48:54.522007+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T20:46:05.255704+01:00","closed_at":"2026-03-19T20:46:05.255704+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.1","depends_on_id":"ade-6","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]}
|
|
65
|
+
{"id":"ade-6.2","title":"Plan","description":"Create a detailed implementation strategy based on your exploration: - If exists: Base your strategy on requirements from it - Otherwise: Use existing task context Break down the work into specific, actionable tasks. Consider edge cases, dependencies, and potential challenges. - If architectural changes needed and exists: Document in - Otherwise: Create tasks to track architectural decisions - If exists: Adhere to the design in it - Otherwise: Elaborate design options and present them to the user Document the planning work thoroughly and create implementation tasks as part of the code phase as needed.","status":"closed","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T16:48:54.661272+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T20:46:05.353452+01:00","closed_at":"2026-03-19T20:46:05.353452+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.2","depends_on_id":"ade-6","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-6.2","depends_on_id":"ade-6.1","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]}
|
|
66
|
+
{"id":"ade-6.3","title":"Code","description":"Follow your plan to build the solution: - If exists: Follow the design from it - Otherwise: Elaborate design options and present them to the user - If exists: Build according to the architecture from it - Otherwise: Elaborate architectural options and present them to the user - If exists: Ensure requirements from it are met - Otherwise: Ensure existing requirements are met based on your task context Write clean, well-structured code with proper error handling. Prevent regression by building, linting, and executing existing tests. Stay flexible and adapt the plan as you learn more during implementation. Update task progress and create new tasks as needed.","status":"closed","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T16:48:54.813402+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T19:29:11.362541+01:00","closed_at":"2026-03-19T19:29:11.362541+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.3","depends_on_id":"ade-6","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-6.3","depends_on_id":"ade-6.2","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]}
|
|
67
|
+
{"id":"ade-6.3.1","title":"Add AdeExtensions interface and AdeExtensionsSchema (Zod) to packages/core/src/types.ts","status":"closed","priority":1,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T17:10:05.210558+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T17:48:15.234448+01:00","closed_at":"2026-03-19T17:48:15.234448+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.3.1","depends_on_id":"ade-6.3","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]}
|
|
68
|
+
{"id":"ade-6.3.2","title":"Add mergeExtensions() to packages/core/src/catalog/index.ts","status":"closed","priority":1,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T17:10:05.382003+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T17:48:15.336955+01:00","closed_at":"2026-03-19T17:48:15.336955+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.3.2","depends_on_id":"ade-6.3","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-6.3.2","depends_on_id":"ade-6.3.1","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]}
|
|
69
|
+
{"id":"ade-6.3.3","title":"Export AdeExtensions, AdeExtensionsSchema, mergeExtensions from packages/core/src/index.ts","status":"closed","priority":1,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T17:10:05.523449+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T17:48:15.438591+01:00","closed_at":"2026-03-19T17:48:15.438591+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.3.3","depends_on_id":"ade-6.3","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-6.3.3","depends_on_id":"ade-6.3.1","type":"blocks","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-6.3.3","depends_on_id":"ade-6.3.2","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]}
|
|
70
|
+
{"id":"ade-6.3.4","title":"Add jiti as CLI dependency and zod as core dependency","status":"closed","priority":1,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T17:10:05.663512+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T17:48:15.53763+01:00","closed_at":"2026-03-19T17:48:15.53763+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.3.4","depends_on_id":"ade-6.3","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]}
|
|
71
|
+
{"id":"ade-6.3.5","title":"Create packages/cli/src/extensions.ts with loadExtensions(projectRoot)","status":"closed","priority":1,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T17:10:05.81068+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T17:48:15.632037+01:00","closed_at":"2026-03-19T17:48:15.632037+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.3.5","depends_on_id":"ade-6.3","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-6.3.5","depends_on_id":"ade-6.3.4","type":"blocks","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-6.3.5","depends_on_id":"ade-6.3.3","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]}
|
|
72
|
+
{"id":"ade-6.3.6","title":"Wire extension loading into packages/cli/src/index.ts (setup + install commands)","status":"closed","priority":1,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T17:10:05.953907+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T17:48:19.642615+01:00","closed_at":"2026-03-19T17:48:19.642615+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.3.6","depends_on_id":"ade-6.3","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-6.3.6","depends_on_id":"ade-6.3.5","type":"blocks","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-6.3.6","depends_on_id":"ade-6.3.7","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]}
|
|
73
|
+
{"id":"ade-6.3.7","title":"Expose buildHarnessWriters(extensions) in packages/harnesses/src/index.ts","status":"closed","priority":1,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T17:10:06.106652+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T17:48:15.854204+01:00","closed_at":"2026-03-19T17:48:15.854204+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.3.7","depends_on_id":"ade-6.3","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]}
|
|
74
|
+
{"id":"ade-6.3.8","title":"Create ade.extensions.mjs SAP example in repo root","status":"closed","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T17:10:06.230083+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T17:48:19.753233+01:00","closed_at":"2026-03-19T17:48:19.753233+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.3.8","depends_on_id":"ade-6.3","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-6.3.8","depends_on_id":"ade-6.3.6","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]}
|
|
75
|
+
{"id":"ade-6.4","title":"Commit","description":"Ensure code quality and documentation accuracy through systematic cleanup and review. **STEP 1: Code Cleanup** Systematically clean up development artifacts: 1. **Remove Debug Output**: Search for and remove all temporary debug output statements used during development. Look for language-specific debug output methods (console logging, print statements, debug output functions). Remove any debugging statements that were added for development purposes. 2. **Review TODO/FIXME Comments**: - Address each TODO/FIXME comment by either implementing the solution or documenting why it's deferred - Remove completed TODOs - Convert remaining TODOs to proper issue tracking if needed 3. **Remove Debugging Code Blocks**: - Remove temporary debugging code, test code blocks, and commented-out code - Clean up any experimental code that's no longer needed - Ensure proper error handling replaces temporary debug logging **STEP 2: Documentation Review** Review and update documentation to reflect final implementation: 1. **Update Long-Term Memory Documents**: Based on what was actually implemented: - If exists: Update it if requirements changed during development - If exists: Update it if architectural impacts were identified - If exists: Update it if design details were refined or changed - Otherwise: Document any changes in the plan file 2. **Compare Against Implementation**: Review documentation against actual implemented functionality 3. **Update Changed Sections**: Only modify documentation sections that have functional changes 4. **Remove Development Progress**: Remove references to development iterations, progress notes, and temporary decisions 5. **Focus on Final State**: Ensure documentation describes the final implemented state, not the development process 6. **Ask User to Review Document Updates** **STEP 3: Final Validation** - Run existing tests to ensure cleanup didn't break functionality - Verify documentation accuracy with a final review - Ensure code is ready for production/delivery Update task progress and mark completed work as you finalize the feature.","status":"closed","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T16:48:54.960844+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T19:37:20.65686+01:00","closed_at":"2026-03-19T19:29:11.477044+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.4","depends_on_id":"ade-6","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"ade-6.4","depends_on_id":"ade-6.3","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]}
|
|
76
|
+
{"id":"ade-6.4.1","title":"e2e integration test: extension option produces skills + knowledge in setup output","status":"closed","priority":1,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-03-19T19:30:47.327614+01:00","created_by":"Oliver Jägle","updated_at":"2026-03-19T19:32:06.768961+01:00","closed_at":"2026-03-19T19:32:06.768961+01:00","close_reason":"Closed","dependencies":[{"issue_id":"ade-6.4.1","depends_on_id":"ade-6.4","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]}
|
package/.beads/last-touched
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
ade-
|
|
1
|
+
ade-6.4.1
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
{
|
|
2
|
+
"conversationId": "ade-main-iazal7",
|
|
3
|
+
"projectPath": "/Users/oliverjaegle/projects/privat/codemcp/ade",
|
|
4
|
+
"epicId": "ade-6",
|
|
5
|
+
"phaseTasks": [
|
|
6
|
+
{
|
|
7
|
+
"phaseId": "explore",
|
|
8
|
+
"phaseName": "Explore",
|
|
9
|
+
"taskId": "ade-6.1"
|
|
10
|
+
},
|
|
11
|
+
{
|
|
12
|
+
"phaseId": "plan",
|
|
13
|
+
"phaseName": "Plan",
|
|
14
|
+
"taskId": "ade-6.2"
|
|
15
|
+
},
|
|
16
|
+
{
|
|
17
|
+
"phaseId": "code",
|
|
18
|
+
"phaseName": "Code",
|
|
19
|
+
"taskId": "ade-6.3"
|
|
20
|
+
},
|
|
21
|
+
{
|
|
22
|
+
"phaseId": "commit",
|
|
23
|
+
"phaseName": "Commit",
|
|
24
|
+
"taskId": "ade-6.4"
|
|
25
|
+
}
|
|
26
|
+
],
|
|
27
|
+
"createdAt": "2026-03-19T15:48:55.317Z",
|
|
28
|
+
"updatedAt": "2026-03-19T15:48:55.317Z"
|
|
29
|
+
}
|
|
@@ -0,0 +1,169 @@
|
|
|
1
|
+
# Development Plan: ade (main branch)
|
|
2
|
+
|
|
3
|
+
*Generated on 2026-03-19 by Vibe Feature MCP*
|
|
4
|
+
*Workflow: [epcc](https://mrsimpson.github.io/responsible-vibe-mcp/workflows/epcc)*
|
|
5
|
+
|
|
6
|
+
## Goal
|
|
7
|
+
|
|
8
|
+
Make the ADE project extensible so that forks/downstream consumers can add new facets, options, and harness writers without modifying the upstream source files. The goal is upstream-compatibility — consumers should be able to pull upstream changes without merge conflicts caused by modifications to core catalog or registry files.
|
|
9
|
+
|
|
10
|
+
## Explore
|
|
11
|
+
<!-- beads-phase-id: ade-6.1 -->
|
|
12
|
+
### Tasks
|
|
13
|
+
- [x] Explore codebase structure: packages/core, packages/harnesses, packages/cli
|
|
14
|
+
- [x] Understand how catalog, registry, and writers are wired together
|
|
15
|
+
- [x] Identify all the places consumers currently need to modify to extend
|
|
16
|
+
|
|
17
|
+
### Findings
|
|
18
|
+
|
|
19
|
+
**Current extension points require modifying upstream files:**
|
|
20
|
+
1. **Adding a new facet/option** → must edit `packages/core/src/catalog/index.ts` (`getDefaultCatalog()`) and add a new file in `catalog/facets/`
|
|
21
|
+
2. **Adding a new provision writer** → must edit `packages/core/src/registry.ts` (`createDefaultRegistry()`)
|
|
22
|
+
3. **Adding a new harness writer** → must edit `packages/harnesses/src/index.ts` (`allHarnessWriters` array + `getHarnessWriter` + `getHarnessIds`)
|
|
23
|
+
4. **Wiring it all into the CLI** → `packages/cli/src/index.ts` calls `getDefaultCatalog()` and relies on `allHarnessWriters` from harnesses
|
|
24
|
+
|
|
25
|
+
**Existing infrastructure that's already extensible:**
|
|
26
|
+
- `WriterRegistry` + `registerProvisionWriter/registerAgentWriter` already exist as a general-purpose registry
|
|
27
|
+
- `Catalog` and `Facet` types are public and composable
|
|
28
|
+
- `createRegistry()` + `createDefaultRegistry()` already allow building custom registries
|
|
29
|
+
- `resolve()` accepts a `Catalog` and `WriterRegistry` — so it's already injection-ready
|
|
30
|
+
- `runSetup(projectRoot, catalog)` already takes a `catalog` parameter
|
|
31
|
+
|
|
32
|
+
**Key insight:** The CLI's `index.ts` is the main wiring point. It hardcodes `getDefaultCatalog()` and `allHarnessWriters`. The CLI needs a plugin/extension loading mechanism so forks can inject their extensions without modifying the upstream entry point.
|
|
33
|
+
|
|
34
|
+
## Plan
|
|
35
|
+
<!-- beads-phase-id: ade-6.2 -->
|
|
36
|
+
|
|
37
|
+
### Phase Entrance Criteria:
|
|
38
|
+
- [x] The codebase has been thoroughly explored
|
|
39
|
+
- [x] Current extension points and blockers are identified
|
|
40
|
+
- [x] It's clear what's in scope and what's out of scope
|
|
41
|
+
|
|
42
|
+
### Tasks
|
|
43
|
+
|
|
44
|
+
*Tasks managed via `bd` CLI*
|
|
45
|
+
|
|
46
|
+
## Code
|
|
47
|
+
<!-- beads-phase-id: ade-6.3 -->
|
|
48
|
+
|
|
49
|
+
### Phase Entrance Criteria:
|
|
50
|
+
- [ ] Design is documented and reviewed
|
|
51
|
+
- [ ] Scope is agreed upon: what changes are needed and where
|
|
52
|
+
- [ ] No open design questions remain
|
|
53
|
+
|
|
54
|
+
### Tasks
|
|
55
|
+
|
|
56
|
+
*Tasks managed via `bd` CLI*
|
|
57
|
+
|
|
58
|
+
## Commit
|
|
59
|
+
<!-- beads-phase-id: ade-6.4 -->
|
|
60
|
+
|
|
61
|
+
### Phase Entrance Criteria:
|
|
62
|
+
- [ ] All code changes are implemented and tested
|
|
63
|
+
- [ ] Existing tests pass
|
|
64
|
+
- [ ] The extension mechanism works end-to-end (catalog + writers + harnesses injectable)
|
|
65
|
+
|
|
66
|
+
### Tasks
|
|
67
|
+
- [ ] Squash WIP commits: `git reset --soft <first commit of this branch>`. Then, create a conventional commit. In the message, first summarize the intentions and key decisions from the development plan. Then, add a brief summary of the key changes and their side effects and dependencies
|
|
68
|
+
|
|
69
|
+
*Tasks managed via `bd` CLI*
|
|
70
|
+
|
|
71
|
+
## Key Decisions
|
|
72
|
+
|
|
73
|
+
### KD-1: Extension model — `ade.extensions.mjs` with declarative contributions
|
|
74
|
+
|
|
75
|
+
A consumer creates `ade.extensions.mjs` (or `.js`) in their project (or in a forked CLI's src dir).
|
|
76
|
+
The CLI loads it via dynamic `import()` at startup and merges contributions before resolving.
|
|
77
|
+
|
|
78
|
+
The extension file exports a default object conforming to `AdeExtensions`:
|
|
79
|
+
|
|
80
|
+
```ts
|
|
81
|
+
interface AdeExtensions {
|
|
82
|
+
// Contribute new options into existing facets (e.g. add "SAP" to "architecture")
|
|
83
|
+
facetContributions?: Record<string, Option[]>
|
|
84
|
+
// Register entirely new facets
|
|
85
|
+
facets?: Facet[]
|
|
86
|
+
// Register new provision writers (e.g. a "sap-config" writer)
|
|
87
|
+
provisionWriters?: ProvisionWriterDef[]
|
|
88
|
+
// Register new harness writers (e.g. a custom IDE)
|
|
89
|
+
harnessWriters?: HarnessWriter[]
|
|
90
|
+
}
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
**Why this model:**
|
|
94
|
+
- `facetContributions` (keyed by facet id) is the right primitive for the SAP use case:
|
|
95
|
+
SAP is a new *option* inside the existing `architecture` facet, not a new facet.
|
|
96
|
+
- `facets` covers the case where a consumer wants to add a completely new facet (e.g. "cloud-provider").
|
|
97
|
+
- `provisionWriters` and `harnessWriters` cover the writer extension cases.
|
|
98
|
+
- The consumer never needs to modify upstream files.
|
|
99
|
+
- Dynamic `import()` means no build step required for `.mjs` extensions.
|
|
100
|
+
|
|
101
|
+
### KD-2: Loading location
|
|
102
|
+
|
|
103
|
+
The extension file is resolved relative to the **project root** passed to the CLI.
|
|
104
|
+
Search order: `ade.extensions.mjs` → `ade.extensions.js` (first match wins).
|
|
105
|
+
This works for both the "consumer uses npx @codemcp/ade setup" case and the "fork scenario".
|
|
106
|
+
|
|
107
|
+
### KD-3: Type exports
|
|
108
|
+
|
|
109
|
+
`AdeExtensions`, `HarnessWriter` (re-exported from harnesses), and all catalog/writer types
|
|
110
|
+
are already exported from `@codemcp/ade-core`. We need to add `AdeExtensions` to the exports.
|
|
111
|
+
No breaking changes to existing APIs.
|
|
112
|
+
|
|
113
|
+
### KD-4: SAP example placement
|
|
114
|
+
|
|
115
|
+
The SAP example (`sap` option on the `architecture` facet) will be implemented as a concrete
|
|
116
|
+
`ade.extensions.mjs` example file **in the repo root** (not bundled into the catalog).
|
|
117
|
+
This doubles as the integration test and documentation for the extension mechanism.
|
|
118
|
+
|
|
119
|
+
### KD-5: Type safety for extension loading → documented in `docs/adrs/0002-extension-file-type-safety.md`
|
|
120
|
+
|
|
121
|
+
Runtime Zod validation (always) + `jiti` for `.ts` extension files + `AdeExtensions` type export for JSDoc consumers.
|
|
122
|
+
|
|
123
|
+
## Notes
|
|
124
|
+
|
|
125
|
+
**SAP Architecture option shape** (what the consumer writes):
|
|
126
|
+
```js
|
|
127
|
+
// ade.extensions.mjs
|
|
128
|
+
import { } from '@codemcp/ade-core' // types only if needed
|
|
129
|
+
|
|
130
|
+
const sapOption = {
|
|
131
|
+
id: 'sap',
|
|
132
|
+
label: 'SAP',
|
|
133
|
+
description: 'SAP development with ABAP, CAP (Cloud Application Programming model), and BTP',
|
|
134
|
+
recipe: [
|
|
135
|
+
{
|
|
136
|
+
writer: 'skills',
|
|
137
|
+
config: {
|
|
138
|
+
skills: [
|
|
139
|
+
{ name: 'sap-architecture', description: '...', body: '...' },
|
|
140
|
+
{ name: 'sap-design', description: '...', body: '...' },
|
|
141
|
+
]
|
|
142
|
+
}
|
|
143
|
+
}
|
|
144
|
+
],
|
|
145
|
+
docsets: [
|
|
146
|
+
{ id: 'cap-docs', label: 'SAP CAP', origin: 'https://github.com/SAP/cloud-sdk.git', description: '...' }
|
|
147
|
+
]
|
|
148
|
+
}
|
|
149
|
+
|
|
150
|
+
export default {
|
|
151
|
+
facetContributions: {
|
|
152
|
+
architecture: [sapOption]
|
|
153
|
+
}
|
|
154
|
+
}
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
The CLI then calls `mergeExtensions(catalog, registry, extensions)` before running setup/install.
|
|
158
|
+
|
|
159
|
+
**Files to create/modify:**
|
|
160
|
+
1. `packages/core/src/types.ts` — add `AdeExtensions` type
|
|
161
|
+
2. `packages/core/src/catalog/index.ts` — add `mergeExtensions(catalog, extensions)` function
|
|
162
|
+
3. `packages/core/src/index.ts` — export `AdeExtensions` and `mergeExtensions`
|
|
163
|
+
4. `packages/cli/src/extensions.ts` — new file: `loadExtensions(projectRoot)` using dynamic import
|
|
164
|
+
5. `packages/cli/src/index.ts` — load extensions and pass merged catalog/registry to setup/install
|
|
165
|
+
6. `packages/harnesses/src/index.ts` — expose `mergeHarnessWriters` or accept additional writers
|
|
166
|
+
7. `ade.extensions.mjs` — example file in repo root with the SAP architecture option
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
*This plan is maintained by the LLM and uses beads CLI for task management. Tool responses provide guidance on which bd commands to use for task management.*
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* ade.extensions.mjs — SAP BTP / ABAP architecture extension example
|
|
3
|
+
*
|
|
4
|
+
* Place this file in your project root to extend the default ADE catalog
|
|
5
|
+
* without modifying any upstream source files.
|
|
6
|
+
*
|
|
7
|
+
* This file serves as both documentation and an integration example.
|
|
8
|
+
* It is by no means functional! It's about providing options with dependent
|
|
9
|
+
* skills and documentation sources.
|
|
10
|
+
* TypeScript consumers can use ade.extensions.ts with full IDE type-checking.
|
|
11
|
+
*
|
|
12
|
+
* @type {import('@codemcp/ade-core').AdeExtensions}
|
|
13
|
+
*/
|
|
14
|
+
export default {
|
|
15
|
+
facetContributions: {
|
|
16
|
+
architecture: [
|
|
17
|
+
{
|
|
18
|
+
id: "sap-abap",
|
|
19
|
+
label: "SAP BTP / ABAP",
|
|
20
|
+
description:
|
|
21
|
+
"SAP Business Technology Platform with ABAP Cloud development",
|
|
22
|
+
recipe: [
|
|
23
|
+
{
|
|
24
|
+
writer: "skills",
|
|
25
|
+
config: {
|
|
26
|
+
skills: [
|
|
27
|
+
{
|
|
28
|
+
name: "sap-abap-architecture",
|
|
29
|
+
source: "your-org/ade-sap/skills/sap-abap-architecture"
|
|
30
|
+
},
|
|
31
|
+
{
|
|
32
|
+
name: "sap-abap-code",
|
|
33
|
+
source: "your-org/ade-sap/skills/sap-abap-code"
|
|
34
|
+
},
|
|
35
|
+
{
|
|
36
|
+
name: "sap-abap-testing",
|
|
37
|
+
source: "your-org/ade-sap/skills/sap-abap-testing"
|
|
38
|
+
}
|
|
39
|
+
]
|
|
40
|
+
}
|
|
41
|
+
},
|
|
42
|
+
{
|
|
43
|
+
writer: "knowledge",
|
|
44
|
+
config: {
|
|
45
|
+
sources: [
|
|
46
|
+
{
|
|
47
|
+
name: "sap-abap-docs",
|
|
48
|
+
origin: "https://your-serialized-version-of-abap-docs.git",
|
|
49
|
+
description: "Official SAP ABAP Cloud development guide"
|
|
50
|
+
}
|
|
51
|
+
]
|
|
52
|
+
}
|
|
53
|
+
}
|
|
54
|
+
],
|
|
55
|
+
docsets: [
|
|
56
|
+
{
|
|
57
|
+
id: "sap-btp-docs",
|
|
58
|
+
label: "SAP BTP",
|
|
59
|
+
origin: "https://your-serialized-version-of-btp-docs.git",
|
|
60
|
+
description: "SAP Business Technology Platform documentation"
|
|
61
|
+
}
|
|
62
|
+
]
|
|
63
|
+
}
|
|
64
|
+
]
|
|
65
|
+
}
|
|
66
|
+
};
|
|
@@ -0,0 +1,97 @@
|
|
|
1
|
+
# ADR 0002: Type Safety Strategy for Extension File Loading
|
|
2
|
+
|
|
3
|
+
## Status
|
|
4
|
+
|
|
5
|
+
Proposed
|
|
6
|
+
|
|
7
|
+
## Context
|
|
8
|
+
|
|
9
|
+
ADE is being made extensible: consumers who fork the repository or use it as an upstream
|
|
10
|
+
can place an `ade.extensions.mjs` (or `.js`, `.ts`) file in their project root to contribute
|
|
11
|
+
new catalog options, facets, provision writers, and harness writers without modifying
|
|
12
|
+
upstream files.
|
|
13
|
+
|
|
14
|
+
The CLI loads this file at runtime via dynamic `import()`. This creates a type safety gap:
|
|
15
|
+
|
|
16
|
+
- `import()` returns `Promise<unknown>`, so the loaded module has no compile-time shape
|
|
17
|
+
guarantee on the CLI side.
|
|
18
|
+
- Consumers writing `.mjs`/`.js` extension files have no TypeScript compiler checking their
|
|
19
|
+
exported object against the `AdeExtensions` interface.
|
|
20
|
+
- Shape errors (wrong property name, wrong recipe format, missing required field) would
|
|
21
|
+
surface as confusing runtime failures deep inside `resolve()` or a writer, not at the
|
|
22
|
+
point of authoring the extension.
|
|
23
|
+
|
|
24
|
+
Three levels of type safety are available:
|
|
25
|
+
|
|
26
|
+
**Level 1 — JSDoc `@type` annotation (authoring-time, opt-in)**
|
|
27
|
+
The consumer annotates their JS extension file with
|
|
28
|
+
`/** @type {import('@codemcp/ade-core').AdeExtensions} */`.
|
|
29
|
+
This provides IDE autocompletion and type hints in editors with JSDoc awareness (VS Code).
|
|
30
|
+
No build step. No CLI-side guarantee — the annotation is advisory only and silently ignored
|
|
31
|
+
if the consumer doesn't use it.
|
|
32
|
+
|
|
33
|
+
**Level 2 — Runtime Zod validation (load-time, mandatory)**
|
|
34
|
+
The CLI validates the loaded module against a Zod schema derived from `AdeExtensions`
|
|
35
|
+
immediately after import. Rejects invalid extensions with a structured, actionable error
|
|
36
|
+
message before any catalog or registry mutation happens.
|
|
37
|
+
No authoring-time feedback, but errors surface at `ade setup` time rather than
|
|
38
|
+
mid-resolution.
|
|
39
|
+
|
|
40
|
+
**Level 3 — TypeScript extension files via `jiti` (authoring-time, opt-in)**
|
|
41
|
+
The CLI's extension loader also accepts `ade.extensions.ts`. Loading it requires an
|
|
42
|
+
in-process TypeScript runner. `jiti` (by the Nuxt/unjs team) is the established solution:
|
|
43
|
+
it strips types at load time using `oxc-transform` (zero native binaries, fast, ESM-native).
|
|
44
|
+
Consumers writing `.ts` extension files get full TypeScript compiler checking and IDE
|
|
45
|
+
support. `jiti` is already used by Vite, Nuxt, and most of the unjs ecosystem.
|
|
46
|
+
|
|
47
|
+
These levels are not mutually exclusive. The fork scenario (consumer edits source TypeScript
|
|
48
|
+
directly in a forked CLI) already has full compile-time safety through the TypeScript
|
|
49
|
+
compiler — no additional mechanism needed there.
|
|
50
|
+
|
|
51
|
+
## Decision
|
|
52
|
+
|
|
53
|
+
We will implement **Level 2 (Zod runtime validation) combined with Level 3 (`.ts` support
|
|
54
|
+
via `jiti`)**, and export the `AdeExtensions` type from `@codemcp/ade-core` to enable
|
|
55
|
+
Level 1 as a zero-cost baseline for JS consumers.
|
|
56
|
+
|
|
57
|
+
Concretely:
|
|
58
|
+
|
|
59
|
+
1. `AdeExtensions` is defined as a TypeScript interface in `@codemcp/ade-core` and exported
|
|
60
|
+
from its public index.
|
|
61
|
+
|
|
62
|
+
2. A corresponding `AdeExtensionsSchema` Zod schema is defined alongside the interface.
|
|
63
|
+
The CLI's `loadExtensions(projectRoot)` function validates every loaded extension object
|
|
64
|
+
against this schema and throws a structured error if validation fails.
|
|
65
|
+
|
|
66
|
+
3. The extension loader searches for files in this order:
|
|
67
|
+
`ade.extensions.ts` → `ade.extensions.mjs` → `ade.extensions.js`
|
|
68
|
+
The first match is loaded. `.ts` files are loaded via `jiti`; `.mjs`/`.js` files via
|
|
69
|
+
native `import()`.
|
|
70
|
+
|
|
71
|
+
4. `jiti` is added as a production dependency of `@codemcp/ade-cli`.
|
|
72
|
+
|
|
73
|
+
## Consequences
|
|
74
|
+
|
|
75
|
+
**Easier:**
|
|
76
|
+
|
|
77
|
+
- Consumers writing `ade.extensions.ts` get full IDE type checking and compile-time errors
|
|
78
|
+
— the same authoring experience as editing the upstream source directly.
|
|
79
|
+
- All consumers (JS and TS) get clear, structured error messages at `ade setup` time if
|
|
80
|
+
their extension file is malformed, rather than cryptic failures during resolution.
|
|
81
|
+
- The `AdeExtensions` type and JSDoc `@type` path give JS consumers a zero-friction
|
|
82
|
+
upgrade path toward type safety without requiring a build step.
|
|
83
|
+
- The fork scenario (editing CLI TypeScript source directly) retains full compile-time
|
|
84
|
+
safety with no additional tooling.
|
|
85
|
+
|
|
86
|
+
**More difficult / trade-offs:**
|
|
87
|
+
|
|
88
|
+
- Adding `jiti` as a dependency introduces a transitive dependency surface (~400 kB
|
|
89
|
+
unpacked, no native binaries). This is a deliberate trade-off accepted in exchange for
|
|
90
|
+
`.ts` extension support.
|
|
91
|
+
- Zod must be kept as a runtime dependency of `@codemcp/ade-core` (it already is, or will
|
|
92
|
+
be added). The `AdeExtensionsSchema` must be kept in sync with the `AdeExtensions`
|
|
93
|
+
interface — a dual-maintenance surface. A build-time `zod-to-ts` or `ts-to-zod` step
|
|
94
|
+
could eliminate this in the future if drift becomes a problem.
|
|
95
|
+
- Dynamic loading of arbitrary user files (via `import()` or `jiti`) means the CLI cannot
|
|
96
|
+
be fully type-checked end-to-end at its own build time. The Zod boundary is the explicit
|
|
97
|
+
trust boundary between upstream-typed code and user-supplied code.
|
|
@@ -0,0 +1,187 @@
|
|
|
1
|
+
# Extending ADE
|
|
2
|
+
|
|
3
|
+
ADE is designed to be forked and extended without modifying upstream source
|
|
4
|
+
files. Drop an `ade.extensions.mjs` (or `.ts` / `.js`) into your project root
|
|
5
|
+
and ADE picks it up automatically on every `ade setup` or `ade install` run.
|
|
6
|
+
|
|
7
|
+
## How it works
|
|
8
|
+
|
|
9
|
+
```
|
|
10
|
+
your-project/
|
|
11
|
+
ade.extensions.mjs ← ADE reads this from process.cwd()
|
|
12
|
+
config.yaml
|
|
13
|
+
config.lock.yaml
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
`npx @codemcp/ade setup` resolves `projectRoot` to `process.cwd()` — the
|
|
17
|
+
directory you run the command from — so the extensions file is always loaded
|
|
18
|
+
from your project, never from the installed CLI package.
|
|
19
|
+
|
|
20
|
+
## The extension file
|
|
21
|
+
|
|
22
|
+
Export a default object conforming to `AdeExtensions`:
|
|
23
|
+
|
|
24
|
+
```js
|
|
25
|
+
// ade.extensions.mjs
|
|
26
|
+
/** @type {import('@codemcp/ade-core').AdeExtensions} */
|
|
27
|
+
export default {
|
|
28
|
+
// Add options to an existing facet
|
|
29
|
+
facetContributions: {
|
|
30
|
+
architecture: [
|
|
31
|
+
/* Option[] */
|
|
32
|
+
]
|
|
33
|
+
},
|
|
34
|
+
|
|
35
|
+
// Add entirely new facets
|
|
36
|
+
facets: [
|
|
37
|
+
/* Facet[] */
|
|
38
|
+
],
|
|
39
|
+
|
|
40
|
+
// Add custom provision writers
|
|
41
|
+
provisionWriters: [
|
|
42
|
+
/* ProvisionWriterDef[] */
|
|
43
|
+
],
|
|
44
|
+
|
|
45
|
+
// Add custom harness writers
|
|
46
|
+
harnessWriters: [
|
|
47
|
+
/* HarnessWriter[] */
|
|
48
|
+
]
|
|
49
|
+
};
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
All fields are optional — include only what you need.
|
|
53
|
+
|
|
54
|
+
For TypeScript with full IDE type-checking, name the file
|
|
55
|
+
`ade.extensions.ts` instead (requires `jiti`, which is bundled with the CLI).
|
|
56
|
+
|
|
57
|
+
## Adding an architecture option
|
|
58
|
+
|
|
59
|
+
The most common case: contributing a new option to the built-in `architecture`
|
|
60
|
+
facet so it appears in the setup wizard alongside TanStack, Node.js, etc.
|
|
61
|
+
|
|
62
|
+
```js
|
|
63
|
+
// ade.extensions.mjs
|
|
64
|
+
/** @type {import('@codemcp/ade-core').AdeExtensions} */
|
|
65
|
+
export default {
|
|
66
|
+
facetContributions: {
|
|
67
|
+
architecture: [
|
|
68
|
+
{
|
|
69
|
+
id: "sap-abap",
|
|
70
|
+
label: "SAP BTP / ABAP",
|
|
71
|
+
description: "SAP BTP ABAP Cloud development",
|
|
72
|
+
recipe: [
|
|
73
|
+
{
|
|
74
|
+
writer: "skills",
|
|
75
|
+
config: {
|
|
76
|
+
skills: [
|
|
77
|
+
// Inline skill — body is written to .ade/skills/<name>/SKILL.md
|
|
78
|
+
{
|
|
79
|
+
name: "sap-abap-code",
|
|
80
|
+
description: "SAP ABAP coding guidelines",
|
|
81
|
+
body: "# SAP ABAP Code\n\nUse ABAP Cloud APIs only. ..."
|
|
82
|
+
},
|
|
83
|
+
// External skill — fetched from a skills server at install time
|
|
84
|
+
{
|
|
85
|
+
name: "sap-abap-architecture",
|
|
86
|
+
source: "your-org/ade-sap/skills/sap-abap-architecture"
|
|
87
|
+
}
|
|
88
|
+
]
|
|
89
|
+
}
|
|
90
|
+
},
|
|
91
|
+
{
|
|
92
|
+
writer: "knowledge",
|
|
93
|
+
config: {
|
|
94
|
+
name: "sap-abap-docs",
|
|
95
|
+
origin: "https://help.sap.com/docs/abap-cloud",
|
|
96
|
+
description: "SAP ABAP Cloud documentation"
|
|
97
|
+
}
|
|
98
|
+
}
|
|
99
|
+
],
|
|
100
|
+
docsets: [
|
|
101
|
+
{
|
|
102
|
+
id: "sap-abap-cloud-docs",
|
|
103
|
+
label: "SAP ABAP Cloud",
|
|
104
|
+
origin: "https://help.sap.com/docs/abap-cloud",
|
|
105
|
+
description: "SAP ABAP Cloud development documentation"
|
|
106
|
+
}
|
|
107
|
+
]
|
|
108
|
+
}
|
|
109
|
+
]
|
|
110
|
+
}
|
|
111
|
+
};
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
After running `ade setup` and selecting `SAP BTP / ABAP`:
|
|
115
|
+
|
|
116
|
+
- Inline skills are staged to `.ade/skills/<name>/SKILL.md` and installed
|
|
117
|
+
to `.agentskills/skills/<name>/` for agent consumption
|
|
118
|
+
- Knowledge sources appear in `config.lock.yaml` under
|
|
119
|
+
`logical_config.knowledge_sources` and can be initialised with
|
|
120
|
+
`npx @codemcp/knowledge init`
|
|
121
|
+
- Docsets appear in the setup wizard's documentation sources step
|
|
122
|
+
|
|
123
|
+
## Adding a new facet
|
|
124
|
+
|
|
125
|
+
```js
|
|
126
|
+
export default {
|
|
127
|
+
facets: [
|
|
128
|
+
{
|
|
129
|
+
id: "deployment",
|
|
130
|
+
label: "Deployment",
|
|
131
|
+
description: "Target deployment platform",
|
|
132
|
+
required: false,
|
|
133
|
+
options: [
|
|
134
|
+
{
|
|
135
|
+
id: "cf",
|
|
136
|
+
label: "Cloud Foundry",
|
|
137
|
+
description: "SAP BTP Cloud Foundry environment",
|
|
138
|
+
recipe: [{ writer: "skills", config: { skills: [...] } }]
|
|
139
|
+
}
|
|
140
|
+
]
|
|
141
|
+
}
|
|
142
|
+
]
|
|
143
|
+
};
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
New facets are appended after the built-in facets in the wizard. To express
|
|
147
|
+
that a facet depends on another (for conditional option filtering), set
|
|
148
|
+
`dependsOn: ["architecture"]` and implement `available()` on individual options.
|
|
149
|
+
|
|
150
|
+
## Adding a harness writer
|
|
151
|
+
|
|
152
|
+
```js
|
|
153
|
+
export default {
|
|
154
|
+
harnessWriters: [
|
|
155
|
+
{
|
|
156
|
+
id: "my-internal-ide",
|
|
157
|
+
label: "Internal IDE",
|
|
158
|
+
description: "Our internal coding assistant",
|
|
159
|
+
async install(logicalConfig, projectRoot) {
|
|
160
|
+
// write whatever config files your IDE expects
|
|
161
|
+
}
|
|
162
|
+
}
|
|
163
|
+
]
|
|
164
|
+
};
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
The harness appears in the setup wizard's "which agents should receive config?"
|
|
168
|
+
multi-select, after the built-in harnesses.
|
|
169
|
+
|
|
170
|
+
## Validation
|
|
171
|
+
|
|
172
|
+
The extensions file is validated with Zod when loaded. If the shape is wrong
|
|
173
|
+
you get a descriptive error at setup time, not a silent no-op:
|
|
174
|
+
|
|
175
|
+
```
|
|
176
|
+
Error: Invalid ade.extensions file at /your-project/ade.extensions.mjs:
|
|
177
|
+
facetContributions: Expected object, received string
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
## What stays upstream-compatible
|
|
181
|
+
|
|
182
|
+
| Upstream file | Status |
|
|
183
|
+
| ------------------------------------ | ------------------------------------------------ |
|
|
184
|
+
| `packages/core/src/catalog/index.ts` | ✅ Never touch — use `facetContributions` |
|
|
185
|
+
| `packages/harnesses/src/index.ts` | ✅ Never touch — use `harnessWriters` |
|
|
186
|
+
| `packages/cli/src/index.ts` | ✅ Never touch — extensions loaded automatically |
|
|
187
|
+
| `ade.extensions.mjs` (your file) | 🔧 Yours to own |
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@codemcp/ade",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.6.0",
|
|
4
4
|
"description": "ADE CLI — Agentic Development Environment setup and configuration tool",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"keywords": [
|
|
@@ -46,7 +46,8 @@
|
|
|
46
46
|
"typescript": "^5.9.3",
|
|
47
47
|
"vitepress": "1.6.2",
|
|
48
48
|
"vitepress-plugin-mermaid": "2.0.17",
|
|
49
|
-
"vitest": "^3.2.4"
|
|
49
|
+
"vitest": "^3.2.4",
|
|
50
|
+
"zod": "4.3.6"
|
|
50
51
|
},
|
|
51
52
|
"dependencies": {
|
|
52
53
|
"yaml": "^2.8.2"
|