Sync agent instructions from main

2026-09-11 15:55:38 +03:00
parent 27df4a3945
commit 07eb3cd12b
2 changed files with 28 additions and 42 deletions
@@ -12,3 +12,13 @@ Use Gitea MCP to coordinate with other agents working on this project.
 - Keep coordination concise and useful. Use the available MCP tools, and report access failures honestly.
 Work autonomously within the user's requested scope and follow the project's existing conventions.
 ## Gitea and harness maintenance
 Keep Gitea resources and files under `harness` directory organized, accurate, and useful for other agents.
 * As work progresses, consolidate duplicated information, update outdated guidance, close resolved or superseded issues, and remove obsolete temporary files. Perform maintenance when useful without letting it displace project work.
 * Preserve a concise, durable record of what was done, decisions and their reasons, validation results, failed approaches, and remaining work. Link relevant issues, pull requests, commits, and releases so future agents can distinguish completed work from work that still needs attention and avoid repeating unsuccessful attempts.
 * Prefer closing, marking as superseded, or archiving historical material over deleting it. Keep current instructions clearly separated from historical records, and link superseded guidance to its replacement.
 * Before removing information or artifacts, check whether they contain unique knowledge, are referenced elsewhere, or are still needed by another agent. Preserve useful findings in the appropriate shared record first, update affected references, and coordinate cleanup that overlaps active work.
 * Keep indexes and entrypoint documents concise and current so agents can quickly find authoritative guidance and relevant history.
@@ -13,7 +13,6 @@ Deliver the product described by the repository, specification, requirements, re
 Persist until the intended outcome is genuinely achieved.
 Do not stop at:
 - research,
 - planning,
 - a plausible conceptual design,
@@ -27,7 +26,6 @@ The final result must be conceptually coherent, technically sound, usable, imple
 Bias toward action and completion.
 Resolve discoverable questions yourself through:
 - repository exploration,
 - web and literature research,
 - primary documentation,
@@ -78,35 +76,27 @@ Maintain a concise durable Task Ledger in `harness/TASK_LEDGER.md`, unless an eq
 It should distinguish:
 ### Goal and success criteria
 What outcome must ultimately exist.
 ### Verified facts
 Facts established from authoritative sources, repository evidence, experiments, or direct observation.
 ### Given facts
 Requirements or constraints explicitly supplied by me.
 ### Assumptions
 Things currently treated as true but not yet verified.
 ### Open questions
 Important unknowns.
 ### Candidate hypotheses / designs
 Competing explanations or approaches that remain plausible.
 ### Decisions
 Choices that have been made, together with their rationale and supporting evidence.
 ### Current strategy
 The current high-level route toward the goal.
 Do not silently convert an assumption into a fact.
@@ -189,7 +179,6 @@ Possible roles include:
 - integration reviewer.
 Give every subagent:
 - one bounded question or responsibility,
 - relevant context,
 - clear boundaries,
@@ -226,19 +215,15 @@ For consequential, uncertain, difficult-to-reverse design problems, do not accep
 Use an idea-tournament process.
 ### Generate
 Produce several materially different candidate solutions or hypotheses.
 Aim for diversity rather than cosmetic variations of one idea.
 ### Explore
 Where useful, assign independent agents to develop promising candidates in greater depth.
 ### Reflect
 Have independent critics examine candidates for:
 - correctness,
 - hidden assumptions,
 - internal consistency,
@@ -253,7 +238,6 @@ Have independent critics examine candidates for:
 Critics should actively attempt to falsify proposals rather than merely improve them.
 ### Rank
 Compare candidates against explicit criteria derived from the actual project goals.
 Prefer pairwise comparison or an explicit decision matrix when the decision is sufficiently important.
@@ -261,7 +245,6 @@ Prefer pairwise comparison or an explicit decision matrix when the decision is s
 Do not rank based on eloquence.
 ### Evolve
 Improve the strongest candidates.
 Combine complementary ideas when a hybrid is genuinely better.
@@ -269,7 +252,6 @@ Combine complementary ideas when a hybrid is genuinely better.
 Introduce a new candidate if criticism reveals that the existing candidate set shares the same flawed assumption.
 ### Decide
 Select an approach only when enough evidence exists to justify convergence.
 Record the decision and why alternatives lost.
@@ -474,7 +456,6 @@ Do not equate technical functionality with usability.
 Use independent reviewers throughout the project, but select reviewers according to the artifact being evaluated.
 A conceptual or semantic design may need:
 - domain review,
 - consistency review,
 - adversarial / falsification review,
@@ -482,7 +463,6 @@ A conceptual or semantic design may need:
 - and user-workflow review.
 A language may need:
 - ambiguity review,
 - grammar / round-trip review,
 - human-editability review,
@@ -490,7 +470,6 @@ A language may need:
 - and version-control review.
 An implementation may need:
 - correctness review,
 - architecture review,
 - requirements review,
@@ -502,7 +481,6 @@ A final release should receive a cross-disciplinary review rather than only a co
 Require concrete findings and evidence.
 For material findings:
 1. verify the finding,
 2. determine whether the problem is conceptual, specification-level, architectural, implementation-level, or interaction-level,
 3. fix it at the correct layer,
@@ -584,11 +562,11 @@ Do not automatically use maximum reasoning for every delegated task.
 Allocate reasoning effort according to the task:
- Use maximum reasoning for foundational semantic, methodological, formalization, metamodel, language-design, cross-domain synthesis, and other consequential hard-to-reverse decisions.
+* Use maximum reasoning for foundational semantic, methodological, formalization, metamodel, language-design, cross-domain synthesis, and other consequential hard-to-reverse decisions.
- Use extra-high reasoning for difficult architecture, UX / workflow design, alternative-solution evaluation, adversarial conceptual review, and unusually difficult implementation problems.
+* Use extra-high reasoning for difficult architecture, UX / workflow design, alternative-solution evaluation, adversarial conceptual review, and unusually difficult implementation problems.
- Use high reasoning for normal implementation, correctness review, targeted research, Computer Use evaluation, debugging, and complex but bounded analysis.
+* Use high reasoning for normal implementation, correctness review, targeted research, Computer Use evaluation, debugging, and complex but bounded analysis.
- Use medium reasoning for code mapping, repository exploration, mechanical implementation, builds, routine tests, log inspection, and other well-defined work.
+* Use medium reasoning for code mapping, repository exploration, mechanical implementation, builds, routine tests, log inspection, and other well-defined work.
- Use lower effort only for genuinely trivial mechanical tasks.
+* Use lower effort only for genuinely trivial mechanical tasks.
 Prefer spending additional reasoning on upstream decisions whose consequences propagate through many downstream artifacts.
@@ -604,9 +582,9 @@ Use GPT-6 Astra model exclusively.
 Create a modern clone of ARCADIA Capella using Rust Iced framework. It should be cross platform (supporting Windows and Linux at least). Use Rust exclusively (wherever possible & practical).
-Focus on making the application modern, extensible, intuitive and easy to use. When writing code and making software architecture decisions focus on long term maintainability, extensibility while making the project friendly for active development
+Focus on making the application modern, extensible, intuitive and easy to use. When writing code and making software architecture decisions focus on long term maintainability, extensibility while making the project friendly for active development 
-Try to address all known problems / downsides of the original ARCADIA Capella software.
+Try to address all known problems / downsides of the original ARCADIA Capella software. 
 Version 1 MVP in the form of working Operational Analysis layer is done.
 Version 2 MVP in the form of working Operation Analysis + System Analysis is done.
@@ -619,33 +597,32 @@ Keep in mind that the target audience for the application are system engineers.
 The application should be a general systems modeling tool, like ARCADIA Capella or SysML v2
-You should implement most of the ARCADIA semantics, while adressing original ARCADIA Capella problems / downsides
+You should implement most of the ARCADIA semantics, while adressing original ARCADIA Capella problems / downsides 
 The original ARCADIA Capella UI is very bloated, clunky, unintuitive and hard to use. In addition, it lacks a number of quality of life features. You should at all cost avoid making the same mistakes as the developers of the original ARCADIA Capella
 You should explore the functionality & UI of the original ARCADIA Capella to take the most useful and powerful ideas from it. While making them modern, easy to use and understand
-Original ARCADIA Capella uses "nested" elements (visually nested) to signify various relationships, such as "Containment relationship" or "Deployment relationship". Instead of using visually noisy arrows / graph edges. I pretty much like this approach and want to see something similar to it in this application
+Original ARCADIA Capella uses "nested" elements (visually nested) to signify various relationships, such as "Containment relationship" or "Deployment relationship". Instead of using visually noisy arrows / graph edges. I pretty much like this approach and want to see something similar to it in this application 
 To explore the original ARCADIA Capella UI & semantics you may use web resources / web search / official and community docs. Or open the original ARCADIA Capella installed on this desktop machine for exploration
 Your second, parallel, goal is to create a textual representation for ARCADIA, similar to SysML v2. So a user can either edit a system model using UI (graphical representation) or text. Both graphical and textual representations should be fully equivalent and have full parity. You may take inspiration from SysML v2. Both graphical and textual representations should have one overarching, concrete, unambiguous spec in reST format, similar to SysML v2 strictness
-The application should support both forms of editing
+The application should support both forms of editing 
-The textual representation should be easily editable and understandble for both humans and AI
+The textual representation should be easily editable and understandble for both humans and AI 
-The textual representation should be easily handled by version control tools such as Git
+The textual representation should be easily handled by version control tools such as Git 
 The underlying semantics of the textual / graphical representation should support traceability of various development artifacts (for example - code, CAD files, electrical schematics, Docx files and anything in between)
 The textual representation editor should have syntax highlighting and linting
-The project should also have a backend server / service that you can deploy. The backend server purpose is to give programmatic access to stored system models. So, there also should be a clear REST API for querying, editing and working with models. The purpose of the REST API is to allow automation, scripting and AI-driven workflows
+The project should also have a backend server / service that you can deploy. The backend server purpose is to give programmatic access to stored system models. So, there also should be a clear REST API for querying, editing and working with models. The purpose of the REST API is to allow automation, scripting and AI-driven workflows 
-An example could be - writing custom plugins for various domain specific software (version control software, CAD software etc...) to establish traceability between development artifacts and a system model
+An example could be - writing custom plugins for various domain specific software (version control software, CAD software etc...) to establish traceability between development artifacts and a system model 
 The desktop application should contain built-in guide / help / tutorial with clear and concise info on modeling concepts, underlying semantics, common modeling scenarios and application features / how to use the app. It should be easy to navigate and explore
-@Computer
+@Computer 
 ### Semantic model / metamodel
 Requirements:
 - Textual notation.
 - Graphical notation.
 - Constraints and calculations.
@@ -658,7 +635,6 @@ Requirements:
 #### Textual notation
 Requirements:
 - Should not have visual noise and clutter.
 - Should have means to reduce cognitive load when developing system models.
 - Should be easily editable by humans. And AI agents.
@@ -672,8 +648,8 @@ Long, homogeneous lists in the UI that require user to scroll far or search for
 ## Active issues / current guidance
-Right now, the behavior & scenarios UI is hard to use. It contains static / uneditable diagrams, which is highly dubious. In addition, user workflow with the behavior & scenarios UI differ significantly from the other UIs - you can't edit diagrams and instead suppose to click on menus for model development
+Right now, the behavior & scenarios UI is hard to use. It contains static / uneditable diagrams, which is highly dubious. In addition, user workflow with the behavior & scenarios UI differ significantly from the other UIs - you can't edit diagrams and instead suppose to click on menus for model development 
---
+--- 
-The current project state is nowhere near the usability of the original ARCADIA Capella (despite its downfalls) or its functionality / semantics. You should focus on that by studying original ARCADIA Capella very closely and implementing its features in a modern, ergonomic and easy to use way
+The current project state is nowhere near the usability of the original ARCADIA Capella (despite its downfalls) or its functionality / semantics. You should focus on that by studying original ARCADIA Capella very closely and implementing its features in a modern, ergonomic and easy to use way