@devflow-core/dsh-devflow 0.7.0 → 0.9.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/assets/presets/devflow-2/agent.cordis.yml +10 -1
- package/assets/skills/devflow-build/references/build-methods.md +2 -0
- package/assets/skills/devflow-core/SKILL.md +8 -0
- package/assets/skills/devflow-docs-followup/SKILL.md +2 -0
- package/assets/skills/devflow-prove/references/proof-recovery-methods.md +2 -0
- package/assets/skills/devflow-spec/references/spec-plan-methods.md +2 -0
- package/package.json +1 -1
|
@@ -88,7 +88,12 @@
|
|
|
88
88
|
# restores THIS text after promotion. The DevFlow paragraph guarantees
|
|
89
89
|
# activation even when the model would otherwise skip reading AGENTS.md; the
|
|
90
90
|
# route table and hard boundaries stay in the devflow-core skill and AGENTS.md
|
|
91
|
-
# (single source, no duplication).
|
|
91
|
+
# (single source, no duplication). The two trailing paragraphs carry the
|
|
92
|
+
# AGENTS.md rules no lifecycle skill owns — Independent Judgment and the
|
|
93
|
+
# fallback output contracts — because `instructionHint: true` (tool-bootstrap
|
|
94
|
+
# above) replaces the workspace AGENTS.md digest with a reference hint once the
|
|
95
|
+
# session is promoted.
|
|
96
|
+
# devflow: ceiling: clause-level restatement checked by scripts/validate-devflow.js, not full semantic alignment; revisit when either AGENTS.md section is reworded.
|
|
92
97
|
- id: persona
|
|
93
98
|
name: '@deepseek-ai/dsh-persona'
|
|
94
99
|
config:
|
|
@@ -97,6 +102,10 @@
|
|
|
97
102
|
|
|
98
103
|
You run DevFlow. Before any development work — creating features, building components, adding functionality, modifying behavior, or defining an unapproved problem-directed change — load the `devflow-core` skill with the skill tool and read its `core-methods.md` reference, then load only the selected lifecycle owner skill. The route table and hard boundaries live in that skill and in AGENTS.md; do not invent lifecycle details. Pure Q&A, lookup, verification, and investigation-only reports need no lifecycle.
|
|
99
104
|
|
|
105
|
+
Independent judgment: before answering or acting, check for false premises, logical leaps, and material missing information; never agree merely to accommodate the user — when disagreeing, state the evidence, risks, and plausible alternative explanations; separate verified facts, inferences, and opinions, and state the evidence boundary when verification is unavailable; name overlooked variables, costs, constraints, and likely biases.
|
|
106
|
+
|
|
107
|
+
Fallback output contracts: design as Goal / Smallest useful plan / Not doing / Impact / Verification; completion as Command / Result / Adversarial review / Judgment (PASS, FAIL, or BLOCKED).
|
|
108
|
+
|
|
100
109
|
- id: agent-instructions
|
|
101
110
|
name: '@deepseek-ai/dsh-agent-instructions'
|
|
102
111
|
config:
|
|
@@ -42,3 +42,5 @@ A function may contain several steps when they form one coherent business narrat
|
|
|
42
42
|
## Build Comments
|
|
43
43
|
|
|
44
44
|
The approved Spec/Plan and local project convention define required code comments. Add a comment when it records a protected contract, failure condition, business rule, compatibility boundary, or other non-obvious reason; inline comments explain reasons, not syntax. Markdown runtime contracts use headings and fixed output shapes rather than narrative comments.
|
|
45
|
+
|
|
46
|
+
When a comment describes behavior, write it from the accepted final state. Regenerate it from the final behavior instead of editing rejected wording; comments never narrate rejected alternatives, session corrections, intermediate attempts, or why-not-X reasoning, and keep only the non-obvious reasons a future maintainer needs.
|
|
@@ -22,6 +22,14 @@ Status: [DevFlow: <node> -> <next> | awaiting approval / in progress]
|
|
|
22
22
|
|
|
23
23
|
While a DevFlow lifecycle node is active, end each user-facing message with one status line: `[DevFlow: <node> -> <next> | awaiting approval / in progress]`. It reflects the current node without reloading the owner skill. Keep progress visible in the persistent UI: maintain a `todo_write` list with one item per active work unit (lifecycle node, background job, or subagent), marking it `completed` the moment it settles, and use `create_goal` for the session's long-running objective.
|
|
24
24
|
|
|
25
|
+
## Delivery Surfaces
|
|
26
|
+
|
|
27
|
+
Final artifacts and their wrappers — titles, filenames, body text, comments, tags, commits, PR text, documents, and handoffs — describe the accepted final state, assuming the reader did not see this session; rejected session-only alternatives, intermediate attempts, and wording corrections stay control data.
|
|
28
|
+
|
|
29
|
+
For each surface, decide whether a session-less reader needs the information: keep an exclusion only when omission would make the artifact inaccurate, unsafe, misleading, or incompatible, or when this surface must explain a real change from the committed or user-approved baseline. Regenerate high-salience names, titles, and openings from the positive target instead of editing rejected wording, and never write an absent option as a labeled absence. Keep real baseline changes, executed external actions, required technical names, diagnostics, tests, and pre-existing user changes.
|
|
30
|
+
|
|
31
|
+
Before completion, reread every user-visible surface and wrapper, including filenames, metadata, and hook rewrites, and recheck after any content change. Keep unrelated changes out of this task's commit, PR, or handoff; keep comparisons, quotations, audits, or migration notes only when the user asked or the surface requires them, and do not add cleanup or no-residue claims.
|
|
32
|
+
|
|
25
33
|
## Context Map
|
|
26
34
|
|
|
27
35
|
Read `skills/devflow-core/references/core-methods.md` before route selection. It supplies Method 0, shared route rules, and the owner map. Do not load all lifecycle references by default.
|
|
@@ -41,6 +41,8 @@ Rules:
|
|
|
41
41
|
|
|
42
42
|
Before writing a selected document, read the current diff, implementation, tests, commands, and user-confirmed decisions. Use project documentation conventions and templates when they exist.
|
|
43
43
|
|
|
44
|
+
Describe the accepted final state: session-only alternatives, intermediate attempts, and corrections stay out of created documents. Regenerate titles and openings from the positive target; keep API names, real removals, executed external actions, diagnostics, tests, and compatibility facts that accuracy requires, and keep unrelated changes out unless the document requires them.
|
|
45
|
+
|
|
44
46
|
When the target project has no relevant convention, use these fallback locations:
|
|
45
47
|
|
|
46
48
|
| Document type | Fallback path |
|
|
@@ -17,6 +17,8 @@ Adversarial review: <acceptance, regressions, activation, proof coverage>
|
|
|
17
17
|
Judgment: PASS / FAIL / BLOCKED
|
|
18
18
|
```
|
|
19
19
|
|
|
20
|
+
Before the completion report, reread every final artifact and its wrapper — filenames, titles, comments, tags, documents, commit or PR text, metadata, hook rewrites, and the report itself — as a reader without access to this session, and describe only the accepted final state. Recheck after any content change; keep deliberate decision records, safety and compatibility facts, real baseline changes, executed external actions, and pre-existing user changes; keep unrelated changes out of this task's commit, PR, or handoff, and do not add cleanup or no-residue claims.
|
|
21
|
+
|
|
20
22
|
`PASS` is Prove's terminal success after Learn review. Proof `FAIL`, `BLOCKED`, a real adversarial gap, unresolved Code Review Blocker/Warning, or incomplete PUA recovery evidence returns its facts to `devflow-core`; Core selects the repair, recovery, or re-clarification path. Prove never infers that next owner.
|
|
21
23
|
|
|
22
24
|
### Quality-Finding Recovery
|
|
@@ -8,6 +8,8 @@ Owner: `devflow-spec` and `devflow-plan`. Load this reference only after Core se
|
|
|
8
8
|
|
|
9
9
|
`devflow-plan` consumes A/B `CUT_PASS` plus an approved design or confirmed Spec. It creates one implementation plan under `docs/plans/`, then waits for user review. An approved A/B Plan directly enters Build; scope-drift facts return to Core.
|
|
10
10
|
|
|
11
|
+
Spec and Plan names, titles, and framing describe the accepted final state, regenerated from the positive target rather than edited from rejected wording. Keep Non-goals and Rejected as deliberate decision records; keep unrelated changes, comparisons, quotations, audits, or migration notes out unless the user asked or the document requires them.
|
|
12
|
+
|
|
11
13
|
A Spec contains Goal, Context, Requirements, Non-goals, Approach, Impact, Acceptance, Verification, Code Documentation, and Open Questions. A Plan states Source, Spec coverage, Cut Decision, External Skills, exact files or anchors, interfaces, current and target behavior, mechanics, call impact, verification, comments, and exclusions.
|
|
12
14
|
|
|
13
15
|
## Plan Contract
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@devflow-core/dsh-devflow",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.9.0",
|
|
4
4
|
"description": "DevFlow for DeepSeek Harness: devflow-2 agent preset + skills + commands + verification scripts, synced into ~/.dsh on host startup.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"engines": {
|