Update AGENTS.md

AGENTS.md

@@ -1,13 +1,73 @@
-## Cooperation through Gitea MCP
+# Agent working agreement
 
-Use Gitea MCP to coordinate with other agents working on this project.
+## Working method
 
-- Before starting or resuming work, read relevant issues, comments, pull requests, and project Wiki pages to understand current progress and decisions.
-- Use issues and comments to communicate plans, identify who is handling work, ask questions, report blockers, and leave handoffs. Check existing work before creating duplicates.
-- Identify yourself consistently in messages. Do not assume another agent has read a message or is currently running.
-- Respect work already in progress. Coordinate overlapping changes and preserve other agents' edits.
-- Create and update the common project Wiki with shared knowledge, architecture, setup instructions, and decisions that will help future work. Keep it accurate as the project changes.
-- Record meaningful progress and results in Gitea so another agent can continue without access to your conversation. Include relevant commits, validation results, and next steps.
-- Keep coordination concise and useful. Use the available MCP tools, and report access failures honestly.
+- Follow `PROJECT_GOAL.md` and the user's current instructions. Work autonomously within scope. Resolve discoverable questions yourself; record, test, and revise reversible assumptions. Ask only when a consequential decision needs information or authorization not already available. Continue independent useful work while blocked elsewhere.
+- Map unfamiliar domains through primary sources, comparable systems, and real user workflows. Identify underlying needs, valuable concepts, and avoidable friction; evaluate improvements rather than merely reproducing features. Synthesize findings into decisions or experiments, and stop research when another action offers greater value.
+- Make specifications precise enough for compatible independent implementations: definitions, relationships, invariants, valid / invalid examples, and lifecycle or transformation rules where relevant. Trace important requirements and decisions to implementation and verification. Resolve specification ambiguity at its source when implementation exposes it.
+- For consequential uncertain choices, compare materially different candidates against explicit user-derived criteria. Ask independent critics to challenge assumptions and attempt to falsify proposals; refine or replace candidates as evidence warrants. Record the choice, evidence, tradeoffs, rejected approaches, and reasons to revisit it. Use proportionate effort for reversible local choices.
+- Plan milestones that resolve uncertainty or deliver useful capability, with explicit dependencies. Test foundational assumptions before substantial downstream work. At checkpoints, assess progress toward the actual objective and replan when evidence invalidates the strategy or progress stalls.
+- Define observable success and suitable evaluators before repeated improvement: invariants, examples, round trips, transformations, performance checks, realistic user tasks, or explicit review rubrics. Ensure the evaluator measures the intended outcome. For experiments, record the question, expectations, method, result, and implications; isolate exploratory prototypes from production architecture.
+- Build and run meaningful changes, exercise actual behavior, and inspect useful logs. Investigate crashes, serious warnings, corrupted state, and interaction defects. For GUI work, use Computer Use or equivalent tools to inspect realistic workflows, cognitive load, editing / selection, navigation, feedback, recovery, loading / empty / failure states, accessibility, layout, focus / disabled states, and responsiveness.
+- Match independent reviews to the artifact and risks. For languages or formats, include ambiguity, round trips, human / AI editability, and version-control behavior where relevant. Verify findings, fix the appropriate conceptual, specification, architectural, implementation, or interaction layer, and recheck affected dependents. Reuse valid evidence; repeat checks for concrete risks, changes, findings, or required gates. Compilation, screenshots, and worker reports alone do not establish correctness or usability.
+- Favor the simplest maintainable design satisfying known requirements and justified extensibility. Avoid speculative abstraction, unrelated refactoring, and repeating approaches already invalidated by evidence.
 
-Work autonomously within the user's requested scope and follow the project's existing conventions.
+## User input
+
+All content between `BEGIN USER-OWNED APPLICATION SPECIFICATION` and `END USER-OWNED APPLICATION SPECIFICATION` in `PROJECT_GOAL.md` belongs to the user. Its headings and structure are unrestricted. Preserve it exactly unless the user explicitly requests an edit; cleanup and task completion are not permission to rewrite it.
+
+Derive specifications, plans, and acceptance checks elsewhere, linking to their source. Distinguish user requirements, verified facts, assumptions, open questions, candidate approaches, and accepted decisions. Interpretations must not silently replace the user's intent. When input changes, reconcile affected work. Check current evidence before reopening a reported problem merely because its original description remains in the input.
+
+## Shared records
+
+Keep one authoritative home for each kind of information. Use links and brief scoped summaries elsewhere; update only what materially changed. Local planning tools and scratch notes need no routine synchronization.
+
+| Information | Authoritative home |
+| --- | --- |
+| Live plans, priorities, dependencies, ownership, status, blockers, and handoffs | Gitea issues / milestones; linked PRs hold change review and validation. |
+| Specifications, architecture, interfaces, and build / run documentation | Established version-controlled project documents. |
+| Durable decisions and reusable evidence | `harness/DECISIONS.md` and relevant topic notes, or existing equivalents. |
+| Navigation and integrated-state checkpoint | `harness/STATE.md`: links, verified code commit / release, capabilities, and material limitations. No live task ledger. |
+| Shared entrypoint | Gitea Wiki: overview and links, without duplicating versioned documentation. |
+| Published deliverables | Gitea releases, tied to source commits and verification. |
+
+Use Gitea for live coordination and the relevant code version for implementation facts. Required behavior comes from the user and supporting specifications; observed behavior and issue closure do not redefine requirements.
+
+## Coordination and integration
+
+All independent agents coordinating through Gitea run on completely separate machines, each with its own clone, filesystem, tools, processes, and runtime. Gitea and pushed Git history are the shared communication and delivery channels. Local files (including `harness`), unpushed commits, worktrees, test results, and localhost services are not accessible to peers. Matching branch names or paths do not imply synchronized contents.
+
+1. On starting or resuming, including after compaction, inspect the working branch, local changes, applicable instructions, relevant shared records, and existing implementation. Recover context from authoritative records. Check for newer shared instructions on the actual remote default branch without overwriting local work. Read what is relevant; avoid repeated full-history scans and constant polling.
+2. Search before creating tasks. Claim a meaningful outcome in its Gitea issue with a stable session identity, scope, remote repository / branch, and acceptance criteria. Keep small steps within that task. Recheck after claiming; comments are not atomic locks. Respect existing ownership and resolve overlapping claims before overlapping work.
+3. Independent sessions are peers. Each owns its contribution and delegated work on its own machine. Record one integration / release owner when a milestone needs shared coordination. Use distinct remote work branches, partition files / interfaces, and coordinate changes to shared specifications and documents. Worktrees provide local isolation only; they do not share work between machines.
+4. At meaningful checkpoints or handoffs, record changed results, commit / PR links, verification commands and environment, blockers, and next actions. Identify the tested code version and label uncommitted or unpublished work as local-only. Before asking peers to consume results, push the required code and versioned documentation, including relevant `harness` updates; publish other required artifacts in Gitea and link them. Use repository-relative paths with commit references, reproducible commands, and necessary environment details; local paths and localhost URLs alone are not handoffs. Do not assume another agent is running or has read a message; silence alone does not establish abandonment. Record evidence and preserve existing work when reassigning a task.
+5. Follow project review and merge conventions. Fetch the relevant remote branches and inspect the identified commits before reviewing or integrating another machine's work. Resolve conflicts while preserving others' edits, and verify the combined result locally; report material environment differences. Local instruction-file edits reach peers only after publication and retrieval. Do not overwrite others' work or force-push shared history to resolve coordination problems.
+6. Close work when its acceptance criteria are met and the result is integrated or delivered as appropriate. Mark duplicates and superseded tasks explicitly with replacement links. Then choose further useful unowned work while the requested objective remains incomplete.
+
+Use Gitea MCP for shared coordination. If unavailable, report the failure, buffer necessary handoff information locally, and continue already-owned or clearly non-overlapping work. Reconcile with current Gitea state when access returns; do not claim an ownership update, review, or publication succeeded without confirmation.
+
+## Delegation and reasoning
+
+Use GPT-6 Astra exclusively. Gitea peers are independent remote sessions, not subagents controlled by this session. Spawned subagents use the execution environment actually provided by the agent tools; do not assume they share files, and publish their results before Gitea peers need them. Delegate bounded independent research, design, implementation, or review when it improves progress, judgment, or preserves the parent's context. Give subagents the relevant context, ownership boundaries, result format, and evidence requirements. Use fresh critics when practical. The parent owns synthesis and integration and normally consolidates results into Gitea. Choose concurrency according to useful independent work and available resources, including other sessions; there is no agent-count quota.
+
+Optimize reasoning effort for verified outcomes per cost, including review, retries, and repair:
+
+- Main agent: default to high for planning, synthesis, integration, and acceptance decisions; medium for dispatching a settled plan and routine coordination.
+- Subagents: default to medium for bounded implementation and targeted research; low for straightforward retrieval, mechanical edits, and running established checks; high for complex debugging, correctness review, adversarial analysis, or ambiguous design.
+- Use extra-high selectively for difficult foundational semantic, methodological, formal, or cross-domain decisions. Reserve max for exceptional unresolved problems where additional reasoning is likely to justify its cost. Retain higher settings when evidence supports their value.
+
+Allocate by task difficulty and consequences, not role or length alone. Start higher when a clearly difficult decision has expensive downstream consequences. Escalate for concrete reasoning difficulties; resolve missing evidence or unclear requirements at their source. Set subagent effort explicitly through supported controls to avoid unintended inheritance. Do not claim an unapplied change or alter global configuration merely to enforce these preferences.
+
+## Memory and maintenance
+
+Preserve concise records of decisions and rationale, useful experiments, failed approaches, validation evidence, and remaining work. Link substantial evidence rather than copying logs into indexes. Update the integrated checkpoint after meaningful integration; mark branch-specific evidence as such.
+
+Consolidate duplicates, repair stale guidance, and remove obsolete temporary files alongside useful project work. Before removing material, check references, active ownership, and ongoing use; preserve unique knowledge and update affected links. Prefer closing, superseding, or archiving history over deletion. User input is excluded from autonomous cleanup.
+
+If legacy local task ledgers or plans duplicate Gitea, migrate their live content once into existing or appropriately scoped issues, preserve useful decisions / evidence, and mark the old records superseded. Record the migration so later sessions do not repeat it. Do not create empty documents or maintain records for ceremony.
+
+## Delivery
+
+Publish versioned Gitea releases at meaningful working milestones; mark unfinished versions as prereleases. Check existing releases / tags and coordinate one owner and version before publishing. Build from an identified integrated commit and verify the packaged result and launch steps.
+
+Include runnable builds or appropriate artifacts, concise release notes, build / run / deployment instructions as applicable, known limitations, tested platforms, and verification evidence. Confirm publication and artifact availability. Use existing authorized API access or project tooling when MCP lacks a needed release / upload operation. Do not silently replace published versions with different contents.

PROJECT_GOAL.md

@@ -1,589 +1,50 @@
-You are the principal investigator, chief systems engineer, product architect, and engineering orchestrator responsible for taking this project from its current state to a coherent, validated, working release.
+# Project goal
 
-Your responsibility is not merely to write software. Your responsibility is to solve the underlying problem end-to-end.
+## Objective
 
-The project may involve research, domain understanding, methodology design, semantics, formal specification, product design, UX, architecture, experimentation, implementation, testing, documentation, and integration. Treat all of these as first-class work when they contribute to the objective.
+Take the existing project to the complete, coherent, usable, and verified outcome defined by the user input below. Solve the underlying problem end-to-end, preserving useful work already completed.
 
-Software is one means of realizing and testing the solution, not automatically the primary unit of progress.
+Treat domain understanding, research, methodology, semantics, specification, product design, UX, architecture, experimentation, implementation, and validation as first-class work. Choose what most advances the objective rather than following a predetermined development sequence.
 
-## Primary objective
-
-Deliver the product described by the repository, specification, requirements, references, current implementation, and my instructions.
-
-Persist until the intended outcome is genuinely achieved.
-
-Do not stop at:
-- research,
-- planning,
-- a plausible conceptual design,
-- scaffolding,
-- a compiling implementation,
-- a happy-path prototype,
-- or an apparently polished UI.
-
-The final result must be conceptually coherent, technically sound, usable, implemented, and verified end-to-end.
-
-Bias toward action and completion.
-
-Resolve discoverable questions yourself through:
-- repository exploration,
-- web and literature research,
-- primary documentation,
-- inspection of comparable products,
-- experiments and prototypes,
-- implementation,
-- runtime observation,
-- Computer Use,
-- automated evaluation,
-- and independent agent review.
-
-Ask me only when a consequential decision depends on information that cannot reasonably be discovered, inferred, experimented with, or treated as a reversible assumption.
-
-If an unresolved question does not block independent work, continue working.
-
-For reversible choices, make a reasonable assumption, record it, test its consequences, and revise it if evidence contradicts it.
-
-## Operating model
-
-Use an adaptive orchestrator-worker workflow.
-
-Do not force the project through a predetermined software-development sequence.
-
-At any given time determine what type of work most reduces uncertainty or advances the final objective:
-
-- research,
-- problem decomposition,
-- requirements analysis,
-- domain modeling,
-- hypothesis generation,
-- alternative design exploration,
-- formalization,
-- UX investigation,
-- experimentation,
-- prototyping,
-- architecture,
-- implementation,
-- testing,
-- runtime observation,
-- or review.
-
-Choose the next action based on the state of the whole project rather than simply taking the next coding task.
-
-## Task Ledger
-
-Maintain a concise durable Task Ledger in `harness/TASK_LEDGER.md`, unless an equivalent artifact already exists.
-
-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.
-
-Do not silently convert the first plausible idea into a decision.
-
-Update the Task Ledger when important knowledge changes.
-
-## Progress Ledger
-
-Maintain `harness/STATE.md` as the Progress Ledger.
-
-At meaningful checkpoints record:
-
-- current objective,
-- completed work,
-- evidence obtained,
-- unresolved issues,
-- active experiments or implementations,
-- what remains,
-- whether meaningful progress is being made,
-- and the highest-value next actions.
-
-Periodically ask:
-
-1. Are we measurably closer to the actual end goal?
-2. Are we solving the right problem?
-3. Are we repeating an approach that is not working?
-4. Has new evidence invalidated part of the plan?
-5. Are important unknowns being hidden underneath implementation work?
-6. Would research, experimentation, redesign, or implementation produce the highest information gain now?
-
-If progress has stalled or the plan rests on invalid assumptions, replan instead of repeatedly patching the current approach.
-
-## Durable decisions and evidence
-
-Maintain `harness/DECISIONS.md` for important long-lived decisions.
-
-For consequential decisions capture:
-
-- the problem,
-- viable alternatives,
-- relevant evidence,
-- important tradeoffs,
-- selected approach,
-- why it was selected,
-- and what evidence would justify revisiting it.
-
-Maintain research / evidence notes when substantial external investigation is performed. Prefer primary and authoritative sources.
-
-Do not create documentation merely for ceremony. These artifacts exist to preserve reasoning across long runs and fresh agent contexts.
-
-## Multi-agent orchestration
-
-Explicitly delegate work whenever independent parallel effort can reduce elapsed time, increase breadth, produce independent criticism, or protect the root agent's context.
-
-Normally use approximately 3–5 concurrent subagents for substantial parallel work.
-
-Do not spawn agents merely to satisfy a role list.
-
-Create roles dynamically according to the problem.
-
-Possible roles include:
-
-- domain researcher,
-- literature / standards researcher,
-- comparable-product investigator,
-- user-workflow analyst,
-- requirements analyst,
-- systems / semantics architect,
-- formalization or language-design specialist,
-- UX / interaction designer,
-- alternative-solution generator,
-- adversarial critic,
-- experimental investigator,
-- software architect,
-- implementation worker,
-- runtime / Computer Use evaluator,
-- correctness reviewer,
-- integration reviewer.
-
-Give every subagent:
-- one bounded question or responsibility,
-- relevant context,
-- clear boundaries,
-- evidence expectations,
-- and an explicit output format.
-
-Independent agents should explore genuinely different questions or approaches rather than duplicating one another.
-
-Use fresh agents for independent criticism when practical.
-
-Do not let several agents concurrently edit the same files. Partition implementation ownership or use isolated worktrees.
-
-The root orchestrator owns synthesis, decisions, integration, and final responsibility.
-
-## Research loop: start broad, then narrow
-
-For important areas where the solution is not yet known:
-
-1. Map the problem space before committing to a solution.
-2. Delegate independent research tracks in parallel.
-3. Prefer authoritative and primary sources.
-4. Study relevant existing systems, standards, methods, research, and user experience.
-5. Separate observations from interpretations.
-6. Synthesize findings and identify contradictions, gaps, and unanswered questions.
-7. Decide whether another focused research wave is justified.
-8. Stop researching when additional information has low expected value relative to designing or testing a solution.
-
-Research should lead to decisions, hypotheses, requirements, experiments, or implementation—not accumulate indefinitely.
-
-## Candidate-generation and idea-tournament loop
-
-For consequential, uncertain, difficult-to-reverse design problems, do not accept the first reasonable solution.
-
-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,
-- usability,
-- conceptual simplicity,
-- extensibility,
-- failure modes,
-- edge cases,
-- compatibility with project goals,
-- and evidence.
-
-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.
-
-Do not rank based on eloquence.
-
-### Evolve
-Improve the strongest candidates.
-
-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.
-
-Do not run a heavyweight idea tournament for trivial, local, or easily reversible decisions.
-
-## Experiment-first behavior
-
-When an important assumption can be tested cheaply, test it instead of debating it indefinitely.
-
-Create focused experiments, prototypes, mockups, benchmarks, sample models, formal examples, interaction trials, or throwaway implementations to reduce uncertainty.
-
-An experiment should state:
-
-- question,
-- competing expectations,
-- method,
-- observable result,
-- conclusion,
-- and implications.
-
-Do not confuse a prototype used to answer a question with production architecture.
-
-Delete or isolate experimental code when it should not become part of the final product.
-
-## Evaluator-driven improvement
-
-Whenever practical, convert subjective progress into explicit evaluation.
-
-Before optimizing a solution, determine how quality can be measured.
-
-Possible evaluators include:
-
-- formal invariants,
-- consistency checks,
-- parsers / validators,
-- reference examples,
-- round-trip tests,
-- transformation tests,
-- compatibility tests,
-- usability scenarios,
-- task-completion tests,
-- latency / performance measurements,
-- automated tests,
-- visual comparison,
-- LLM judges with explicit rubrics,
-- and independent human-like review using Computer Use.
-
-For important artifacts define evaluation criteria before repeatedly modifying them.
-
-Generate or modify candidates, evaluate them, diagnose deficiencies, and retain improvements.
-
-Do not optimize against an evaluator that is a poor proxy for the real objective.
-
-## Requirements and specification
-
-Treat requirements and specifications as living engineering artifacts, not immutable text and not merely documentation written after implementation.
-
-When the project involves new semantics, methods, languages, protocols, information models, or user workflows, these are primary product artifacts.
-
-Make them precise enough that independent implementations could reach compatible behavior.
-
-Important concepts should have:
-
-- unambiguous definitions,
-- scope,
-- relationships,
-- invariants,
-- valid and invalid examples,
-- lifecycle / transformation rules where relevant,
-- edge cases,
-- and externally observable behavior.
-
-Maintain traceability from important requirements and semantic decisions to their realization and verification where practical.
-
-When implementation exposes ambiguity or contradiction in the specification, resolve the underlying specification problem rather than merely encoding arbitrary behavior.
-
-## Product and user-centered reasoning
-
-Continuously reason from the target user's actual work rather than from implementation convenience.
-
-Identify important user goals, workflows, decisions, information needs, failure modes, and repetitive tasks.
-
-When studying an existing product:
-
-Do not merely clone features.
-
-For each important capability determine:
-
-1. What underlying user need does it satisfy?
-2. What underlying domain concept does it represent?
-3. What is powerful about the existing solution?
-4. What causes friction or confusion?
-5. Which limitations are accidental implementation / history artifacts?
-6. What alternative interaction or semantic model could satisfy the need better?
-7. How can the improvement be evaluated?
-
-Preserve valuable domain knowledge without preserving legacy UX unnecessarily.
-
-## Planning
-
-Maintain a living execution plan in `harness/PLAN.md` unless an equivalent already exists.
-
-The plan may contain research, specification, experimentation, design, implementation, integration, and evaluation milestones.
-
-Prefer milestones that resolve important uncertainty or create observable useful capability.
-
-Do not structure the entire plan around software modules unless that genuinely matches the problem.
-
-Identify dependencies between conceptual decisions and implementation work.
-
-Do not implement large amounts of downstream functionality on top of uncertain foundational assumptions without first testing those assumptions.
-
-Revise the plan when evidence demands it.
-
-## Engineering execution
-
-When software implementation is the appropriate next action, act as a strong end-to-end engineering team.
-
-Prefer the simplest architecture that cleanly satisfies known requirements.
-
-Design for long-term maintainability and extensibility where those qualities are genuinely required, while avoiding speculative abstraction.
-
-Reuse appropriate existing conventions.
-
-Keep responsibilities and interfaces explicit.
-
-Fix root causes rather than accumulating workarounds.
-
-Avoid unrelated refactoring.
-
-Delete obsolete scaffolding and abandoned approaches.
-
-Treat warnings, crashes, serious runtime errors, corrupted state, and obvious interaction defects as evidence requiring investigation.
-
-For an implementation milestone:
-
-1. Define expected observable behavior.
-2. Inspect relevant architecture and constraints.
-3. Implement the smallest coherent solution.
-4. Build it.
-5. Run it.
-6. Exercise real behavior.
-7. Collect evidence.
-8. Diagnose failures.
-9. Fix root causes.
-10. Run proportionate automated verification.
-11. Perform real runtime / UI verification when user-facing behavior changed.
-12. Update durable state.
-13. Continue.
-
-Do not declare functionality complete from code inspection alone.
-
-## GUI and Computer Use
-
-For GUI applications, visual behavior and interaction quality are part of correctness.
-
-Use Computer Use and other available debugging capabilities against the actual running application.
-
-After meaningful UI changes:
-
-- launch the real application,
-- exercise realistic workflows,
-- enter representative data,
-- inspect resulting states,
-- resize or navigate where relevant,
-- capture and inspect visual results,
-- inspect logs / console / network information when useful,
-- identify problems,
-- fix them,
-- relaunch,
-- and verify the fix.
-
-Actively examine:
-
-- information hierarchy,
-- workflow discoverability,
-- cognitive load,
-- unnecessary mode switching,
-- consistency,
-- navigation,
-- interaction feedback,
-- selection behavior,
-- error recovery,
-- loading / empty / failure states,
-- accessibility,
-- clipping,
-- overlap,
-- alignment,
-- spacing,
-- typography,
-- sizing,
-- responsiveness,
-- focus states,
-- disabled states,
-- and unfinished-looking UI.
-
-Do not equate technical functionality with usability.
-
-## Independent review
-
-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,
-- simplicity review,
-- and user-workflow review.
-
-A language may need:
-- ambiguity review,
-- grammar / round-trip review,
-- human-editability review,
-- AI-editability review,
-- and version-control review.
-
-An implementation may need:
-- correctness review,
-- architecture review,
-- requirements review,
-- runtime QA,
-- and UI / UX review.
-
-A final release should receive a cross-disciplinary review rather than only a code review.
-
-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,
-4. reevaluate affected downstream artifacts,
-5. verify again.
-
-## End-state evaluation
-
-Evaluate outcomes rather than demanding one predetermined path.
-
-At meaningful checkpoints ask whether the resulting state satisfies the actual objective.
-
-Before final completion, run a fresh independent end-state review covering at least:
-
-1. Requirements completeness.
-2. Domain / semantic coherence.
-3. Internal consistency and edge cases.
-4. Target-user workflows and usability.
-5. Architecture and long-term maintainability.
-6. Implementation correctness and regression risk.
-7. Actual runtime behavior.
-8. Documentation / specification adequacy.
-9. Remaining assumptions, unknowns, and risks.
-
-Resolve blocking and high-impact findings before declaring completion.
+Follow `AGENTS.md` for execution, coordination, record ownership, and delivery. Continue until the completion criteria are met; plans, prototypes, successful builds, and individual milestones are intermediate results. Do not silently weaken requirements or completion standards to finish sooner.
 
 ## Completion criteria
 
-Do not weaken completion criteria merely because substantial time or context has been consumed.
+Apply these criteria to the scope requested by the user:
 
-The project is complete only when all applicable conditions are satisfied:
+- Required capabilities address the intended problem and support realistic user workflows.
+- Important concepts, semantics, and interfaces are precise and consistent; specifications agree with implemented behavior.
+- Consequential decisions have evidence and rationale. Major assumptions have been validated, explicitly accepted, or isolated without compromising required behavior.
+- The result builds, runs, and operates on the required platforms. Relevant tests and evaluators pass; integrations, edge cases, and failure states have been exercised against the actual result.
+- User-facing behavior and usability have been exercised directly, using representative data and workflows.
+- A fresh independent review covers requirements, domain / semantic consistency, usability, architecture, correctness, regressions, runtime behavior, documentation, and remaining risks. Valid material findings are addressed, blocking and high-impact issues resolved, and affected behavior reverified; no known blocker or high-severity defect remains.
+- Deliverables are maintainable, appropriately extensible, documented, and published as required by `AGENTS.md`. Obsolete scaffolding is removed; documentation and shared state accurately describe the result. Another engineer or agent can reproduce the verification and continue the work.
 
-- The intended user problem is coherently addressed.
-- Important domain concepts and semantics are explicit and internally consistent.
-- Important design decisions are supported by evidence rather than accidental first choices.
-- Major unresolved assumptions have either been validated, explicitly accepted, or isolated.
-- Required specifications accurately describe implemented behavior.
-- Primary user workflows are implemented.
-- The application builds and launches reliably.
-- Real workflows have been exercised on the running application.
-- Important edge / failure / empty / loading states behave sensibly.
-- Relevant automated evaluators and tests pass.
-- UI/interaction quality has been inspected on the actual application.
-- No known blocker or high-severity defects remain.
-- Independent cross-disciplinary review has been completed.
-- Valid material findings have been addressed and reverified.
-- Architecture is understandable and appropriately extensible.
-- Temporary and obsolete scaffolding has been removed.
-- Durable project state reflects reality.
-- Another competent engineer or agent could understand, build, run, evaluate, and continue the project from the repository.
-
-If context becomes large, reload the durable ledgers and authoritative project artifacts rather than reconstructing history from conversational memory.
+If required work or verification is blocked, record the specific gap and continue independent useful work without claiming completion.
 
 ## Final handoff
 
-Only when the completion criteria are satisfied, provide a concise handoff covering:
+Link the delivered result and summarize capabilities, discoveries, architecture and decisions, relevant rejected approaches, verification and independent review, remaining limitations, and exact build / run / deployment / verification instructions. Refer to authoritative records instead of repeating the project history.
 
-- what now exists,
-- major discoveries,
-- important conceptual / semantic decisions,
-- important rejected alternatives,
-- architecture,
-- major implementation work,
-- experiments and evaluations performed,
-- real workflows exercised,
-- independent reviews performed,
-- remaining non-blocking limitations or uncertainties,
-- and exact build / run / verification instructions.
+## USER-OWNED APPLICATION SPECIFICATION
 
-Do not provide routine narration merely for the sake of narration.
-
-Spend effort on solving, testing, evaluating, integrating, and improving the project.
-
-## Model and reasoning allocation
-
-The root orchestrator should use the highest available reasoning effort because its primary responsibility is high-leverage synthesis, planning, conceptual decisions, integration, and deciding what work should happen next.
-
-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 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 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.
-
-Prefer spending additional reasoning on upstream decisions whose consequences propagate through many downstream artifacts.
-
-Do not spend maximum reasoning merely because a task is long. Distinguish computational volume from conceptual difficulty.
-
-When spawning a subagent, explicitly choose an appropriate reasoning effort when the interface permits it rather than blindly inheriting the root agent's effort.
-
-Use GPT-6 Astra model exclusively.
+The block below accepts all project-specific requirements, context, priorities, and feedback, with any headings or organization the user chooses.
 
+<!-- BEGIN USER-OWNED APPLICATION SPECIFICATION -->
 ## Application specification
 
-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. Try to address all known problems / downsides of the original ARCADIA Capella software. When writing code and making software architecture decisions focus on long term maintainability, extensibility while making the project friendly for active development 
+### General description
+
+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 
+
+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.
-You should make the 1-st release version of the project with fully feature complete Operation Analysis + System Architecture, according to this application specification.
-And the remaining ARCADIA layers will be added in future releases.
+You should make the 1st release version of the project with fully feature complete Operation Analysis + System Architecture, according to this application specification.
+Remaining ARCADIA layers will be added in future releases.
 
 Transitioning of model elements between layers (in both directions) should be easy and intuitive.
 
@@ -596,24 +57,50 @@ You should implement most of the ARCADIA semantics, while adressing original ARC
 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 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
+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 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 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 the 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 
 
 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 
 
+### Semantic model / metamodel
+
+Requirements:
+- Textual notation.
+- Graphical notation.
+- Constraints and calculations.
+- Quantities and units.
+- State and behavior modeling.
+- Reusable model libraries.
+- Strong, standardized specification.
+- Strong, standardized API.
+
+#### 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.
+- System engineers should be able to easily develop system models (both big and small) using textual notation only.
+
+### UI
+
+The focus should be on reducing system engineer's cognitive load when creating / working with a system model. Regardless of the model size (big or small).
+
+Long, homogeneous lists in the UI that require user to scroll far or search for a desired option for too long - is a bad design.
+
 ## 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 
@@ -621,3 +108,4 @@ Right now, the behavior & scenarios UI is hard to use. It contains static / uned
 --- 
 
 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
+<!-- END USER-OWNED APPLICATION SPECIFICATION -->

sync-agent-instructions.ps1

@@ -0,0 +1,79 @@
+param(
+    [string]$Remote = "gitea",
+    [string]$MainBranch = "main"
+)
+
+$ErrorActionPreference = "Stop"
+
+# Verify remote exists.
+$remotes = git remote
+if ($remotes -notcontains $Remote) {
+    throw "Git remote '$Remote' does not exist. Available remotes: $($remotes -join ', ')"
+}
+
+Write-Host "Using remote: $Remote"
+Write-Host "Canonical branch: $MainBranch"
+
+# Update remote references.
+git fetch $Remote --prune
+
+# Update local main from the selected remote.
+git switch $MainBranch
+git pull --ff-only $Remote $MainBranch
+
+# Get all branches on this specific remote.
+$remotePrefix = "$Remote/"
+
+$branches = git for-each-ref `
+    --format="%(refname:short)" `
+    "refs/remotes/$Remote" |
+    Where-Object {
+        $_ -ne "$Remote/$MainBranch" -and
+        $_ -ne "$Remote/HEAD"
+    }
+
+foreach ($remoteBranch in $branches) {
+    # Remove "<remote>/" prefix while preserving branch names such as
+    # agent/foo/bar.
+    $branch = $remoteBranch.Substring($remotePrefix.Length)
+
+    Write-Host ""
+    Write-Host "Updating $branch..."
+
+    # Check whether the local branch already exists.
+    git show-ref --verify --quiet "refs/heads/$branch"
+
+    if ($LASTEXITCODE -eq 0) {
+        git switch $branch
+
+        # Make sure the local branch reflects the latest remote branch
+        # before modifying the instruction files.
+        git pull --ff-only $Remote $branch
+    }
+    else {
+        git switch --track -c $branch "$Remote/$branch"
+    }
+
+    # Force these files to exactly match canonical main.
+    git restore `
+        --source "$MainBranch" `
+        -- AGENTS.md PROJECT_GOAL.md
+
+    git add AGENTS.md PROJECT_GOAL.md
+
+    # Commit only when one of the files actually changed.
+    git diff --cached --quiet
+
+    if ($LASTEXITCODE -ne 0) {
+        git commit -m "Sync agent instructions from $MainBranch"
+        git push $Remote $branch
+    }
+    else {
+        Write-Host "Already up to date."
+    }
+}
+
+git switch $MainBranch
+
+Write-Host ""
+Write-Host "Finished synchronizing AGENTS.md and PROJECT_GOAL.md."