archgraph-argo 0.10.27 → 0.10.29
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 +2 -1
- package/argo/rules/archgraph.instructions.md +23 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -29,6 +29,7 @@ ArchGraph deploys the ARGO toolchain to all major coding-agent environments:
|
|
|
29
29
|
| Cursor | ✓ | ✓ | ✓ | ✓ | — |
|
|
30
30
|
| OpenCode | ✓ | ✓ | ✓ | ✓ | ✓ |
|
|
31
31
|
| DeepSeek Harness | ✓ | ✓ | ✓ | ✓ | ✓ |
|
|
32
|
+
| OpenClaw | ✓ | ✓ | ✓ | — | ✓ |
|
|
32
33
|
|
|
33
34
|
A single `argo-deploy` registers the `argo` MCP server and installs all artifacts into each harness
|
|
34
35
|
automatically.
|
|
@@ -40,7 +41,7 @@ npm install -g archgraph-argo
|
|
|
40
41
|
argo-deploy
|
|
41
42
|
```
|
|
42
43
|
|
|
43
|
-
Done — the ARGO toolchain, skills, and rules are deployed, and the `argo` MCP server is registered automatically in **GitHub Copilot**, **Cursor**, **OpenCode**,
|
|
44
|
+
Done — the ARGO toolchain, skills, and rules are deployed, and the `argo` MCP server is registered automatically in **GitHub Copilot**, **Cursor**, **OpenCode**, **DeepSeek Harness** (dsh), and **OpenClaw**.
|
|
44
45
|
|
|
45
46
|
> Semantic (Graph RAG) queries also need **Neo4j** and a **vector engine** configured in
|
|
46
47
|
> `~/.argo/.env`; everything else works out of the box.
|
|
@@ -17,7 +17,7 @@ The following are non-negotiable red lines (MUST) for this Agent and must never
|
|
|
17
17
|
1. Before modifying anything in the repository, you MUST first locate (or create) the corresponding architecture element and View in the graph through the ARGO MCP. See `<IntentArchitectureFirst>`.
|
|
18
18
|
2. The intent graph must only be read/written through the ARGO MCP tools; direct editing of the graph source file (design/KG/SystemArchitecture.json) is forbidden. See `<ToolsGuideline>`.
|
|
19
19
|
3. Every change must be committed via git, and the "commit id + related file paths" must be registered in the `commit` attribute of the corresponding architecture element. See `<IntentArchitectureFirst>` item 4.
|
|
20
|
-
4. Any change must first identify and pass the regression tests of all affected acceptance test cases; if the acceptance test cases are missing, add them first. See `<AcceptanceTestFirst>`.
|
|
20
|
+
4. Any change must first identify and pass the regression tests of all affected acceptance test cases; if the acceptance test cases are missing, add them first. Tier 1 (behavior-independent) changes are exempt from acceptance regression and full validation per `<ChangeTierGate>`; all other tiers keep the full requirement. See `<AcceptanceTestFirst>` and `<ChangeTierGate>`.
|
|
21
21
|
5. Before finishing work, you MUST summarize the key progress of this session and write it back to long-term memory, to prevent forgetting across long or separate sessions. See `<SessionMemorySummarization>` and `<MemoryTriggerTiming>`.
|
|
22
22
|
6. Continuously comply with the red lines above throughout the process; never skip, simplify, or silently violate any of them.
|
|
23
23
|
</CoreRules>
|
|
@@ -54,6 +54,21 @@ When you are about to build an element, first look up the skills and resources n
|
|
|
54
54
|
6. Every acceptance test case in the knowledge graph MUST be described and implemented in GIVEN-WHEN-THEN format, so it is both human-readable and automatically executable.
|
|
55
55
|
</AcceptanceTestFirst>
|
|
56
56
|
|
|
57
|
+
<ChangeTierGate>
|
|
58
|
+
Every repository change MUST be classified into exactly one tier BEFORE implementation; the tier is declared explicitly. Tier classification is objective and enumerable; if the Agent cannot conclusively classify the change, it MUST default to Tier 2 (fail-safe).
|
|
59
|
+
1. Tier 1 — 行为无关(behavior-independent): qualifies ONLY if ALL of the following hold:
|
|
60
|
+
- The diff touches only non-executable content: comments, documentation (including this rules file), whitespace/formatting-only hunks, or descriptive metadata text in the intent graph.
|
|
61
|
+
- No executable logic, public interface/API surface, or test logic is changed (test files untouched).
|
|
62
|
+
- No graph structure change: no element/relationship/view added, removed, renamed, or retyped.
|
|
63
|
+
- Skipped ceremony(跳过验收回归与全量校验): acceptance test identification and regression, and full validateSystemArchitecture, are skipped (unless the graph was touched). Kept ceremony: locate the element, git commit + register commit id, and defer memory milestone writes to session end.
|
|
64
|
+
2. Tier 2 — 行为变化(behavior-changing, scoped): any change touching executable logic, interfaces, or test behavior within existing elements. Full ceremony: locate element, identify affected acceptance test cases, run regression, validateSystemArchitecture, commit + register, immediate memory writes.
|
|
65
|
+
3. Tier 3 — 结构性/新增(structural/new): new elements/relationships/views, new features, or cross-cutting changes. Full Tier 2 ceremony plus preview/apply mutation for any graph change.
|
|
66
|
+
4. Safety net (MUST, non-negotiable):
|
|
67
|
+
- Declared tier is verified at commit time: the actual git diff file list is checked against the Tier 1 allowlist; if any disallowed file/hunk appears, the change automatically 升为 Tier 2 and MUST complete the acceptance regression and validation before finishing. Tier 1 is revocable, not merely declared.
|
|
68
|
+
- KG 触线规则: any diff touching design/KG/SystemArchitecture.json keeps full validation; the Tier 1 exemption never applies to graph structure changes.
|
|
69
|
+
- 零歧义默认升档(fail-safe): any uncertain classification MUST be treated as Tier 2, never Tier 1.
|
|
70
|
+
</ChangeTierGate>
|
|
71
|
+
|
|
57
72
|
<CoperationGuideline>
|
|
58
73
|
0. You must not do the work of another `Business Actor`; you may only work in the role you are delegated to and must strictly stay within that role's responsibilities. If you need help from another `Business Actor`, you must go through a formal delegation process.
|
|
59
74
|
1. When you need to delegate to a `Business Actor`, look it up in the intent graph by its stable identity (`name` or `id`, registered at creation): if it already exists, delegate to it directly; if not, create the `Business Actor` element and register a globally unique `name`.
|
|
@@ -62,6 +77,13 @@ When you are about to build an element, first look up the skills and resources n
|
|
|
62
77
|
4. Each `Business Actor` must stay isolated from other `Business Actor`s while working, i.e., each uses its own independent session/working context and must not interfere with others.
|
|
63
78
|
</CoperationGuideline>
|
|
64
79
|
|
|
80
|
+
<CapabilityDelegationGuideline>
|
|
81
|
+
1. When an Agent receives a task that requires viewing or reading images (图片), videos (视频), or other multimodal (多模态) content, it MUST first assess whether its own model has the recognition capability to consume that content.
|
|
82
|
+
2. If the Agent's model lacks that capability (不具备识别能力), or the harness fails to deliver the content, the Agent MUST NOT (不得) guess, fabricate, or silently skip the content; it MUST proactively identify another `Business Actor` in the intent graph whose agent/model has the required capability (via the Actor's `agent`/`model` attributes or description) and formally delegate (委托) that subtask to that Actor per `<CoperationGuideline>` (look up the stable identity; launch the corresponding Agent, or fall back to a general-purpose Agent passing that Actor's description).
|
|
83
|
+
3. If no capable Actor can be found, the Agent MUST report the exact blocking reason and alternatives to the human partner instead of pretending to have consumed the content.
|
|
84
|
+
4. After delegation, the delegating Agent remains responsible for verifying the delegated result against the original task's acceptance criteria (external view), keeping the executable GIVEN-WHEN-THEN validation principle intact.
|
|
85
|
+
</CapabilityDelegationGuideline>
|
|
86
|
+
|
|
65
87
|
<SessionMemorySummarization>
|
|
66
88
|
Before every session ends (before finishing work), you MUST perform a short-term memory summarization and write the summary into long-term memory — a SUBVIEW hierarchy mounted under the relevant `Business Actor` element, i.e. Views whose `parent_element_id` points to that Actor (create the first sub-view if none exists; you may mount multiple sub-views under the Actor, or expand new sub-views under the elements of an existing sub-view, forming a hierarchical long-term memory system) — refreshing long-term memory to prevent cross-session forgetting:
|
|
67
89
|
1. First read the short-term (session) memory: check the records of this session under `/memories/session/`; if empty, summarize based on the actual work done in this session.
|
package/package.json
CHANGED