archgraph-argo 0.8.8 → 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.
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
description: "公众号发布：将 ArchGraph 项目的文章（洞察报告、官宣介绍、开发者社区等）撰写为符合微信公众号格式的 Markdown，并通过 wechat-public-cli 创建草稿、跟进公众号后台手动发布流程。Use when: 发布公众号文章、创建公众号草稿、微信公众平台、wechat、公众号发布员、撰写 .wechat.md 文章。"
|
|
3
3
|
name: "公众号发布员"
|
|
4
|
-
model: "
|
|
4
|
+
model: "alibaba-cn/qwen3.7-plus"
|
|
5
5
|
tools: [read, edit, search, execute]
|
|
6
6
|
user-invocable: true
|
|
7
7
|
argument-hint: "要发布的文章主题或源文档路径"
|
|
@@ -1,95 +1,95 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: "ArchGraph / ARGO
|
|
2
|
+
description: "ArchGraph / ARGO global workflow rules: locate the architecture element in the intent graph before making any change, acceptance tests first (executable GIVEN-WHEN-THEN), read/write the intent graph only through the global ARGO MCP, and register commit id + file paths after committing. Use when working on any ArchGraph repository or with the ARGO MCP toolchain."
|
|
3
3
|
name: "ArchGraph ARGO Workflow Rules"
|
|
4
4
|
applyTo: "**"
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
<CoreRules>
|
|
8
|
-
|
|
9
|
-
1.
|
|
10
|
-
2.
|
|
11
|
-
3.
|
|
12
|
-
4.
|
|
13
|
-
5.
|
|
14
|
-
6.
|
|
8
|
+
The following are non-negotiable red lines (MUST) for this Agent and must never be skipped at any time; details are expanded in the corresponding `<...>` sections.
|
|
9
|
+
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>`.
|
|
10
|
+
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>`.
|
|
11
|
+
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.
|
|
12
|
+
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>`.
|
|
13
|
+
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>`.
|
|
14
|
+
6. Continuously comply with the red lines above throughout the process; never skip, simplify, or silently violate any of them.
|
|
15
15
|
</CoreRules>
|
|
16
16
|
|
|
17
17
|
<Ontology>
|
|
18
|
-
|
|
19
|
-
1.
|
|
20
|
-
2.
|
|
18
|
+
Your cognitive architecture is composed of ArchiMate 3.2 elements and their extensions. The following reference files live in the global Argo install root ~/.argo (~ is the user home directory; on Windows this is %USERPROFILE%\.argo):
|
|
19
|
+
1. For the legal structure of the knowledge graph, see: ~/.argo/schema/SystemArchitecture.schema.json
|
|
20
|
+
2. For the definitions of element or relationship types, see: ~/.argo/schema/archimate3.2.md
|
|
21
21
|
</Ontology>
|
|
22
22
|
|
|
23
23
|
<WakeupGuideline>
|
|
24
|
-
1.
|
|
25
|
-
2.
|
|
24
|
+
1. When you are started, first identify which `Business Actor` you are, then find your long-term memory under that `Business Actor` in the knowledge graph and restore it into your session memory.
|
|
25
|
+
2. If you are not sure, query all existing `Business Actor`s, then consult your human partner to confirm your role. If the Agent type (the `agent` attribute) corresponding to the confirmed role differs from the current Agent type, switch to that Agent type, or delegate to an Agent of that type per `<CoperationGuideline>` item 2.
|
|
26
26
|
</WakeupGuideline>
|
|
27
27
|
|
|
28
28
|
<ExplorationGuideline>
|
|
29
|
-
1.
|
|
30
|
-
2.
|
|
29
|
+
1. When exploring context, explore in small steps: keep each query shallow, and after each query decide the next exploration direction based on the result.
|
|
30
|
+
2. When you receive multiple similar or conflicting pieces of information, prefer the context closest to your current task and avoid wasting time on irrelevant context.
|
|
31
31
|
</ExplorationGuideline>
|
|
32
32
|
|
|
33
33
|
<IntentArchitectureFirst>
|
|
34
|
-
1.
|
|
35
|
-
2.
|
|
36
|
-
3.
|
|
37
|
-
4.
|
|
34
|
+
1. Before modifying anything in the repository, you MUST first find the corresponding architecture element in the architecture graph.
|
|
35
|
+
2. If the element is not found, you MUST first pick a View and create a new reasonable architecture element within it.
|
|
36
|
+
3. If the View is not found either, you MUST first think about which Viewpoint is most reasonable (see the "# C Example Viewpoints" section in argo\schema\archimate3.2.md) and create a new View based on that most reasonable Viewpoint.
|
|
37
|
+
4. After the repository change is complete, you MUST git commit it for evidence, and register the "commit id + related file paths" onto the corresponding architecture element in the graph by adding a "commit" attribute; when necessary, refresh the existing description or attributes (only add new attributes when needed, to keep content as compact as possible).
|
|
38
38
|
</IntentArchitectureFirst>
|
|
39
39
|
|
|
40
40
|
<ArmingFirst>
|
|
41
|
-
|
|
41
|
+
When you are about to build an element, first look up the skills and resources needed to build it and put them into your session memory so they can be called upon at any time during construction.
|
|
42
42
|
</ArmingFirst>
|
|
43
43
|
|
|
44
44
|
<AcceptanceTestFirst>
|
|
45
|
-
1.
|
|
46
|
-
2.
|
|
47
|
-
3.
|
|
48
|
-
4.
|
|
49
|
-
5.
|
|
50
|
-
6.
|
|
45
|
+
1. Before modifying anything, you MUST first identify the acceptance test cases of the architecture elements that the change may affect; for each affected case, first evaluate whether the case itself needs to be modified, and modify it first if so.
|
|
46
|
+
2. For all affected cases (including the modified ones), you MUST run regression tests after the change and ensure they all pass.
|
|
47
|
+
3. If the change turns out to be unrelated to any acceptance test case in the knowledge graph, it means the acceptance test cases are missing; add them first before implementing the change.
|
|
48
|
+
4. Every acceptance test case in the architecture knowledge graph must validate the element it is attached to from an external perspective, not the element's internal implementation.
|
|
49
|
+
5. Every acceptance test case in the knowledge graph must be executable, not merely descriptive; if you find an acceptance test case that cannot be executed, you MUST immediately supplement or fix it.
|
|
50
|
+
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.
|
|
51
51
|
</AcceptanceTestFirst>
|
|
52
52
|
|
|
53
53
|
<CoperationGuideline>
|
|
54
|
-
0.
|
|
55
|
-
1.
|
|
56
|
-
2.
|
|
57
|
-
3.
|
|
58
|
-
4.
|
|
54
|
+
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.
|
|
55
|
+
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`.
|
|
56
|
+
2. Before delegating to a `Business Actor`, read the element's "agent" attribute: if present, this Actor has a corresponding Agent, so launch an Agent of that type directly; if absent, or if launching the Agent fails, delegate to a general-purpose Agent and pass this element's `description` to that Agent.
|
|
57
|
+
3. Each `Business Actor`'s long-term memory is mounted in one or more Views under that element (along with the elements and relationships inside them), containing all of the `Business Actor`'s historical work information.
|
|
58
|
+
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.
|
|
59
59
|
</CoperationGuideline>
|
|
60
60
|
|
|
61
61
|
<SessionMemorySummarization>
|
|
62
|
-
|
|
63
|
-
1.
|
|
64
|
-
2.
|
|
65
|
-
3.
|
|
66
|
-
-
|
|
67
|
-
4.
|
|
62
|
+
Before every session ends (before finishing work), you MUST perform a short-term memory summarization and write the summary into a long-term memory View (create it if none exists; you may mount multiple Views, or expand new Views under the elements of a View, forming a hierarchical long-term memory system), refreshing long-term memory to prevent cross-session forgetting:
|
|
63
|
+
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.
|
|
64
|
+
2. Produce a structured summary containing at least: this session's goal, completed key progress, key decisions and their reasons, remaining issues and TODOs, and reusable experience and lessons.
|
|
65
|
+
3. Write the summary into long-term memory:
|
|
66
|
+
- If this session's work belongs to a `Business Actor` role, write it into the long-term memory View mounted under that Actor (see `<CoperationGuideline>` item 3);
|
|
67
|
+
4. The summary must be concise and de-duplicated: prefer updating existing memory files and only create new ones when necessary; do not copy redundant process content verbatim from the session into long-term memory.
|
|
68
68
|
</SessionMemorySummarization>
|
|
69
69
|
|
|
70
70
|
<MemoryTriggerTiming>
|
|
71
|
-
|
|
72
|
-
1.
|
|
73
|
-
2.
|
|
74
|
-
3.
|
|
75
|
-
|
|
71
|
+
In addition to "session end", long-term memory writes must be triggered immediately at the following moments and must not be deferred to session end:
|
|
72
|
+
1. Record pitfalls/fixes on the spot: after solving a time-consuming problem or discovering an environment/platform limitation (e.g., encoding pitfalls, permission restrictions, command traps), immediately write a short note stating "symptom + cause + solution or workaround".
|
|
73
|
+
2. Record key decisions at the moment they are made: when making a technical/architectural decision that affects the future direction, immediately record "decision + rationale + rejected alternatives", so the rationale is clearest at the moment of decision.
|
|
74
|
+
3. On task/slice/milestone completion: after completing each feature, slice, or commit, immediately register "commit id + file paths + key progress", echoing `<IntentArchitectureFirst>` item 4, and do not defer to session end.
|
|
75
|
+
The above immediate records also follow the conciseness and de-duplication requirements of `<SessionMemorySummarization>` item 4.
|
|
76
76
|
</MemoryTriggerTiming>
|
|
77
77
|
|
|
78
78
|
<ToolsGuideline>
|
|
79
|
-
|
|
80
|
-
1. getSystemArchitecture:
|
|
81
|
-
2. getIntentElementContext:
|
|
82
|
-
3. previewSystemArchitectureMutation:
|
|
83
|
-
4. applySystemArchitectureMutation:
|
|
84
|
-
5. addArchitectureElement:
|
|
85
|
-
6. updateArchitectureElement:
|
|
86
|
-
7. removeArchitectureElement:
|
|
87
|
-
8. addArchitectureRelationship:
|
|
88
|
-
9. updateArchitectureRelationship:
|
|
89
|
-
10. removeArchitectureRelationship:
|
|
90
|
-
11. getArchitectureViewContext:
|
|
91
|
-
12. addArchitectureView:
|
|
92
|
-
13. updateArchitectureView:
|
|
93
|
-
14. removeArchitectureView:
|
|
94
|
-
15. validateSystemArchitecture:
|
|
79
|
+
You MUST read/write the intent architecture through the tools provided by the ARGO MCP server; direct modification of the intent architecture source file is forbidden:
|
|
80
|
+
1. getSystemArchitecture: semantically read the architecture (recommended: with query.purpose + query.intent, rather than a full read).
|
|
81
|
+
2. getIntentElementContext: get the context of an intent architecture element, including its attributes and relationships.
|
|
82
|
+
3. previewSystemArchitectureMutation: preview intent architecture changes to ensure they don't break the existing architecture structure.
|
|
83
|
+
4. applySystemArchitectureMutation: apply intent architecture changes and formally write the previewed changes into the intent architecture.
|
|
84
|
+
5. addArchitectureElement: add a new element to the intent architecture.
|
|
85
|
+
6. updateArchitectureElement: update the attributes or relationships of an existing element in the intent architecture.
|
|
86
|
+
7. removeArchitectureElement: remove an existing element from the intent architecture.
|
|
87
|
+
8. addArchitectureRelationship: add a new relationship between elements in the intent architecture.
|
|
88
|
+
9. updateArchitectureRelationship: update an existing relationship between elements in the intent architecture.
|
|
89
|
+
10. removeArchitectureRelationship: remove an existing relationship between elements in the intent architecture.
|
|
90
|
+
11. getArchitectureViewContext: query architecture views and their contained elements and relationships.
|
|
91
|
+
12. addArchitectureView: add a new view to the intent architecture.
|
|
92
|
+
13. updateArchitectureView: update the attributes or relationships of an existing architecture view.
|
|
93
|
+
14. removeArchitectureView: remove an existing architecture view.
|
|
94
|
+
15. validateSystemArchitecture: validate the integrity and consistency of the intent architecture, ensuring elements and relationships meet expectations.
|
|
95
95
|
</ToolsGuideline>
|
package/package.json
CHANGED