sorokin.oleg.edu/ARCADIA-Studio
1
0
Fork 0
Code Issues 37 Pull Requests 2 Packages Projects Releases 9 Wiki Activity

Sync agent instructions from main

Browse Source
This commit is contained in:
sorokin.oleg.edu
2026-09-11 15:55:38 +03:00
parent 27df4a3945
commit 07eb3cd12b
2 changed files with 28 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+10
View File
@@ -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. - 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. 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.
PROJECT_GOAL.md
+5 -29
View File
@@ -13,7 +13,6 @@ Deliver the product described by the repository, specification, requirements, re
Persist until the intended outcome is genuinely achieved. Persist until the intended outcome is genuinely achieved.
Do not stop at: Do not stop at:
- research, - research,
- planning, - planning,
- a plausible conceptual design, - a plausible conceptual design,
@@ -27,7 +26,6 @@ The final result must be conceptually coherent, technically sound, usable, imple
Bias toward action and completion. Bias toward action and completion.
Resolve discoverable questions yourself through: Resolve discoverable questions yourself through:
- repository exploration, - repository exploration,
- web and literature research, - web and literature research,
- primary documentation, - primary documentation,
@@ -78,35 +76,27 @@ Maintain a concise durable Task Ledger in `harness/TASK_LEDGER.md`, unless an eq
It should distinguish: It should distinguish:
### Goal and success criteria ### Goal and success criteria
What outcome must ultimately exist. What outcome must ultimately exist.
### Verified facts ### Verified facts
Facts established from authoritative sources, repository evidence, experiments, or direct observation. Facts established from authoritative sources, repository evidence, experiments, or direct observation.
### Given facts ### Given facts
Requirements or constraints explicitly supplied by me. Requirements or constraints explicitly supplied by me.
### Assumptions ### Assumptions
Things currently treated as true but not yet verified. Things currently treated as true but not yet verified.
### Open questions ### Open questions
Important unknowns. Important unknowns.
### Candidate hypotheses / designs ### Candidate hypotheses / designs
Competing explanations or approaches that remain plausible. Competing explanations or approaches that remain plausible.
### Decisions ### Decisions
Choices that have been made, together with their rationale and supporting evidence. Choices that have been made, together with their rationale and supporting evidence.
### Current strategy ### Current strategy
The current high-level route toward the goal. The current high-level route toward the goal.
Do not silently convert an assumption into a fact. Do not silently convert an assumption into a fact.
@@ -189,7 +179,6 @@ Possible roles include:
- integration reviewer. - integration reviewer.
Give every subagent: Give every subagent:
- one bounded question or responsibility, - one bounded question or responsibility,
- relevant context, - relevant context,
- clear boundaries, - clear boundaries,
@@ -226,19 +215,15 @@ For consequential, uncertain, difficult-to-reverse design problems, do not accep
Use an idea-tournament process. Use an idea-tournament process.
### Generate ### Generate
Produce several materially different candidate solutions or hypotheses. Produce several materially different candidate solutions or hypotheses.
Aim for diversity rather than cosmetic variations of one idea. Aim for diversity rather than cosmetic variations of one idea.
### Explore ### Explore
Where useful, assign independent agents to develop promising candidates in greater depth. Where useful, assign independent agents to develop promising candidates in greater depth.
### Reflect ### Reflect
Have independent critics examine candidates for: Have independent critics examine candidates for:
- correctness, - correctness,
- hidden assumptions, - hidden assumptions,
- internal consistency, - internal consistency,
@@ -253,7 +238,6 @@ Have independent critics examine candidates for:
Critics should actively attempt to falsify proposals rather than merely improve them. Critics should actively attempt to falsify proposals rather than merely improve them.
### Rank ### Rank
Compare candidates against explicit criteria derived from the actual project goals. 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. 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. Do not rank based on eloquence.
### Evolve ### Evolve
Improve the strongest candidates. Improve the strongest candidates.
Combine complementary ideas when a hybrid is genuinely better. 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. Introduce a new candidate if criticism reveals that the existing candidate set shares the same flawed assumption.
### Decide ### Decide
Select an approach only when enough evidence exists to justify convergence. Select an approach only when enough evidence exists to justify convergence.
Record the decision and why alternatives lost. 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. Use independent reviewers throughout the project, but select reviewers according to the artifact being evaluated.
A conceptual or semantic design may need: A conceptual or semantic design may need:
- domain review, - domain review,
- consistency review, - consistency review,
- adversarial / falsification review, - adversarial / falsification review,
@@ -482,7 +463,6 @@ A conceptual or semantic design may need:
- and user-workflow review. - and user-workflow review.
A language may need: A language may need:
- ambiguity review, - ambiguity review,
- grammar / round-trip review, - grammar / round-trip review,
- human-editability review, - human-editability review,
@@ -490,7 +470,6 @@ A language may need:
- and version-control review. - and version-control review.
An implementation may need: An implementation may need:
- correctness review, - correctness review,
- architecture review, - architecture review,
- requirements 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. Require concrete findings and evidence.
For material findings: For material findings:
1. verify the finding, 1. verify the finding,
2. determine whether the problem is conceptual, specification-level, architectural, implementation-level, or interaction-level, 2. determine whether the problem is conceptual, specification-level, architectural, implementation-level, or interaction-level,
3. fix it at the correct layer, 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: 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. Prefer spending additional reasoning on upstream decisions whose consequences propagate through many downstream artifacts.
@@ -645,7 +623,6 @@ The desktop application should contain built-in guide / help / tutorial with cle
### Semantic model / metamodel ### Semantic model / metamodel
Requirements: Requirements:
- Textual notation. - Textual notation.
- Graphical notation. - Graphical notation.
- Constraints and calculations. - Constraints and calculations.
@@ -658,7 +635,6 @@ Requirements:
#### Textual notation #### Textual notation
Requirements: Requirements:
- Should not have visual noise and clutter. - Should not have visual noise and clutter.
- Should have means to reduce cognitive load when developing system models. - Should have means to reduce cognitive load when developing system models.
- Should be easily editable by humans. And AI agents. - Should be easily editable by humans. And AI agents.