opensddrag 0.2.0 → 0.2.2

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "opensddrag",
3
- "version": "0.2.0",
3
+ "version": "0.2.2",
4
4
  "description": "CLI client to connect any project to the OpenSddRag SDD+Harness MCP server",
5
5
  "keywords": [
6
6
  "sdd",
@@ -7,18 +7,27 @@ export const applySkill = {
7
7
  body: (slug, note) => `# OpenSddRag — Apply
8
8
  ${note}## When to use
9
9
  To implement tasks one at a time, validating each against its spec acceptance criteria before
10
- marking it done. Read ALL planning artifacts (proposal + specs + design) as context first.
10
+ marking it done. Read the design (and, per task, the spec it implements) as context — the
11
+ proposal is not re-read during apply, since the design already encodes its decisions.
11
12
 
12
13
  ## Inputs
13
14
  $ARGUMENTS = change name, or a specific task name.
14
15
 
15
16
  ## Workflow
16
17
 
17
- ### Step 1 — Load full planning context
18
- \`get_working_context(project_slug="${slug}")\`
19
- \`read_artifact(name="<change-name>-proposal", project_slug="${slug}")\`
20
- \`read_artifact(name="<change-name>-design", project_slug="${slug}")\`
21
- Get and read all specs linked to this change.
18
+ ### Step 1 — Load implementation context
19
+ 1. Load the working context:
20
+ \`get_working_context(project_slug="${slug}")\`
21
+ 2. Fetch the list of all artifacts to serve as the freshness oracle:
22
+ \`list_artifacts(project_slug="${slug}")\`
23
+ 3. Retrieve the change's design content (\`<change-name>-design\`):
24
+ - Locate the design artifact in the \`list_artifacts\` results to get its \`id\` and \`updated_at\`.
25
+ - If no design exists, output "Design missing for change '<change-name>'. Run /opsr:design before /opsr:apply." and STOP.
26
+ - Look up the design's \`id\` in the working context's \`context.content_cache\` (if present):
27
+ - **CACHE HIT:** If the cache entry exists and its \`updated_at\` matches the oracle's \`updated_at\`, use the cached design content. Do not call \`read_artifact\`.
28
+ - **CACHE MISS/STALE:** If the cache entry is missing or its \`updated_at\` does not match, call \`read_artifact(name="<change-name>-design", project_slug="${slug}")\`. Then, update the working context cache by calling \`update_working_context\` with \`context.content_cache[<artifact_id>] = {type: "design", content: "<content>", updated_at: "<updated_at>"}\`.
29
+ 4. Do NOT read the proposal during apply — its rationale is already captured in the design.
30
+ 5. Read the specific spec a task implements pointwise at validation time (Step 6) using the same caching logic (check cache, hit → use, miss/stale → read and cache). Tasks themselves are never cached.
22
31
 
23
32
  ### Step 2 — List pending tasks
24
33
  \`list_artifacts(type="task", status="active", project_slug="${slug}")\`
@@ -57,7 +66,7 @@ ${harnessChecklistBlock(slug, "on_apply", "Marking the task archived")}
57
66
  - Task status advanced draft → active → archived in the database.
58
67
 
59
68
  ## Important rules
60
- - Read ALL planning artifacts before implementing — never code from the task alone.
69
+ - Read the design and the task's spec before implementing — never code from the task alone. Do not re-read the proposal during apply.
61
70
  - Run the harness checklist (on_apply) BEFORE marking a task archived; STOP on any error-severity rule.
62
71
  - One task at a time; do not batch-archive tasks.
63
72
  `,
@@ -13,21 +13,21 @@ $ARGUMENTS = change name. If not provided, list active changes and ask.
13
13
 
14
14
  ## Workflow
15
15
 
16
- ### Step 1 — Get the full status of the change
17
- \`list_artifacts(type="proposal", project_slug="${slug}")\`
18
- \`get_relationships(name="<change-name>-proposal", project_slug="${slug}")\`
19
- Gather all linked artifacts (specs, design, tasks).
16
+ ### Step 1 — Load the change bundle
17
+ \`read_change_bundle(change_name="<change-name>", project_slug="${slug}")\`
18
+ Archiving sweeps every artifact of the change, so load them all in one call. The
19
+ response carries the proposal, design, specs, and the task list
20
+ (\`tasks[] = {name, status}\`) with \`task_count\`. Proceed to Step 2.
20
21
 
21
22
  ### Step 2 — Validate artifact completion
22
- \`list_artifacts(type="task", status="draft", project_slug="${slug}")\`
23
+ From the bundle's \`tasks[]\`, treat any task whose \`status\` is not \`archived\` as pending.
23
24
  If pending tasks exist → warn the user and ask for confirmation to archive anyway.
24
25
 
25
26
  ### Step 3 — Validate task completion
26
- Count draft vs archived tasks. If any draft tasks remain → warn and confirm.
27
+ Count pending vs archived tasks from the bundle. If any non-archived tasks remain → warn and confirm.
27
28
 
28
29
  ### Step 4 — Check for delta specs that need syncing
29
- \`list_artifacts(type="spec", project_slug="${slug}")\`
30
- Filter for metadata.change_name = "<change-name>" AND metadata.is_delta = true.
30
+ From the bundle's \`specs[]\`, filter for metadata.change_name = "<change-name>" AND metadata.is_delta = true.
31
31
  If deltas exist: show the affected capabilities and ask "Sync delta specs to main specs now? (recommended)".
32
32
  - If yes → run the /opsr:sync workflow (load the opensddrag-sync skill) for each delta.
33
33
  - If no → archive without syncing.
@@ -49,7 +49,7 @@ const frontmatter = (name, description) =>
49
49
  */
50
50
  export function getSkills(slug, serverUrl) {
51
51
  const note = `> **MCP server:** \`opensddrag\` (${serverUrl}) | **project_slug:** \`${slug}\`
52
- > **Available tools:** \`create_artifact\`, \`read_artifact\`, \`list_artifacts\`, \`update_artifact\`, \`validate_artifact\`, \`link_artifacts\`, \`get_relationships\`, \`search_semantic\`, \`recall_episodes\`, \`get_working_context\`, \`update_working_context\`, \`record_trace\`, \`get_harness_checklist\`
52
+ > **Available tools:** \`create_artifact\`, \`read_artifact\`, \`list_artifacts\`, \`read_change_bundle\`, \`update_artifact\`, \`validate_artifact\`, \`link_artifacts\`, \`get_relationships\`, \`search_semantic\`, \`recall_episodes\`, \`get_working_context\`, \`update_working_context\`, \`record_trace\`, \`get_harness_checklist\`
53
53
  > If these tools are not in your active tool list, the \`opensddrag\` MCP server is not connected — STOP and inform the user.\n\n`;
54
54
 
55
55
  return SKILLS.map((skill) => ({
@@ -14,16 +14,19 @@ $ARGUMENTS = change name.
14
14
 
15
15
  ## Workflow
16
16
 
17
- ### Step 1 — Load all artifacts
18
- \`read_artifact(name="<change-name>-proposal", project_slug="${slug}")\`
19
- \`read_artifact(name="<change-name>-design", project_slug="${slug}")\`
20
- \`get_relationships(name="<change-name>-proposal", project_slug="${slug}")\`
21
- Read each linked spec and task artifact.
17
+ ### Step 1 — Load the change bundle
18
+ \`read_change_bundle(change_name="<change-name>", project_slug="${slug}")\`
19
+ Verification is holistic, so load everything in one call. The response carries the
20
+ proposal, design, full specs, and a task list (\`tasks[] = {name, status}\`) with
21
+ \`task_count\`. If \`task_count\` does not equal the number of returned task entries,
22
+ report an **incomplete bundle** for the change and STOP before declaring verification
23
+ complete. Otherwise proceed — do **not** issue additional \`read_artifact\` calls for
24
+ the proposal, design, or specs.
22
25
 
23
26
  ### Step 2 — Verify COMPLETENESS
24
- \`list_artifacts(type="task", status="draft", project_slug="${slug}")\`
27
+ From the bundle's \`tasks[]\`, treat any task whose \`status\` is not \`archived\` as pending.
25
28
  - If pending tasks exist → **CRITICAL: Tasks not complete**.
26
- Extract every REQ-NNN from the specs and search the codebase for implementation evidence.
29
+ Extract every REQ-NNN from the bundle's specs and search the codebase for implementation evidence.
27
30
  - If a requirement has no evidence → **CRITICAL: Requirement not implemented**.
28
31
 
29
32
  ### Step 3 — Verify CORRECTNESS