Sync agent instructions from main

AGENTS.md

@@ -0,0 +1,73 @@
+# Agent working agreement
+
+## Working method
+
+- 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.
+
+## 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

@@ -0,0 +1,111 @@
+# Project goal
+
+## 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.
+
+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.
+
+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
+
+Apply these criteria to the scope requested by the user:
+
+- 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.
+
+If required work or verification is blocked, record the specific gap and continue independent useful work without claiming completion.
+
+## Final handoff
+
+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.
+
+## USER-OWNED APPLICATION SPECIFICATION
+
+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
+
+### 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 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.
+
+Keep in mind that the target audience for the application are system engineers. And you should satisfy their needs and use cases
+
+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 
+
+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 
+
+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 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 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 
+
+--- 
+
+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 -->

harness/STATE.md

@@ -1,113 +1,38 @@
-# First release — current engineering state
+# First release continuation pointer — 2026-09-06
 
-## Objective and phase
+The goal is active and incomplete. This C: checkout remains a continuation pointer
+with older production code. Do substantial work in the active integration checkout,
+not here; read its STATE, PLAN and TASK_LEDGER before continuing:
 
-The first-release goal remains active and incomplete. Deliver usable Rust/Iced
-Operational Analysis and System Analysis/System Architecture, equivalent graphical,
-textual and REST semantics, artifact traceability, directly editable behavior,
-offline guidance, and Windows/Linux release evidence. Later Arcadia layers remain
-future releases. The full authoritative objective was reread on 2026-09-06:
-attachment07aee762-7d27-4cbe-81c3-2e82c7170711/goal-objective.md.
-PLAN.md retains the entire release scope; no subsystem acceptance completes it.
+D:/CodexBuilds/Capella2-data-integration (codex/data-contract-integration).
+Current production cf04ff1, root native/evidence checkpoint follows it.
+Linux peer D:/CodexBuilds/Capella2-data-linux-review, b5db730.
+Authoritative objective: attachment10134df9-bea2-4c02-a820-67b53d6b86f7/goal-objective.md.
 
-Direct state-machine editing is accepted through production316dc55. The main
-checkout can fast-forward to this integration. R6 data/interface contracts are now
-being implemented in a separate checkout; they are not accepted or released.
-Meaningful implementation and runtime progress continues; no external blocker exists.
+R6 contracts, direct behavior, source5/core/REST/scalar and closed constructor GUI
+are integrated. Full Windows767/Linux770 workspace tests, strict checks and release
+builds passed before newest desktop constructor/help slice; its platform gates run.
+REST live184schemas/19typed values/9 malformed rejections passed earlier. No remote
+service was deployed. Native Windows hosted publish, exact includes/comments,
+graph/text Save, invalid-draft rejection, API artifact review/Reload/Undo/Redo,
+revision conflicts, offline recovery, local copy and catalog Open were exercised.
+That trial closed0/empty stderr. Source/history/ports/routing/explorer/state and
+basic advanced behavior have scoped native Windows/Linux evidence in active ledgers.
 
-## Accepted foundations
+Current high-impact issue: installed invalid local repair source retained a previous
+hosted handle, allowing repaired source to save to the old resource. Actual-App/HTTP
+red reproduction exists; HOST owns minimal fix and fresh reviewer. A separate stale
+empty catalog UX fix follows. Native verification is required after both fixes.
+GUI worker owns independent reset/member/literal decisions in SEM; other keyed/order/
+artifact/multi-source decisions remain. Whole release coverage, advanced native cases,
+Home/recovery/help and final cross-disciplinary acceptance/packaging are unfinished.
 
-- Core typed OA/SA semantics, validated atomic commands and ordinary history are
-  shared by three Rust crates. Typed ports, explicit unresolved migration and
-  original Capella observations: release-port-{contract,core,migration}.md and
-  release-capella-workflow-benchmark.md.
-- Explorer/port discovery d364d3c: Add port on participants, grouped roots, focused
-  children, breadcrumbs, contextual paging/search and full-depth outline. Actual
-  Windows creation,251-root/12-level trials,1100x700 and Linux reopen/font fixes:
-  release-explorer-usability.md.
-- Routing23535b4, viewport366ce44, labels65fa9ab: authored bends/labels, group
-  movement, fold restoration, Undo/Redo, save/reopen and SVG, including minimum-size
-  native trials. Dense full solve measured119ms; arbitrary crossings remain possible.
-  See release-routing-verification.md and release-routing-linux.md.
-- Source4e8575b: nested lexical ownership/includes, provenance-aware token writes,
-  exact accepted source/model history, retained drafts, Save All/recovery and coupled
-  hosted source/model revisions. Windows/Linux native and actual REST restart,
-  stale ETag, comment-only edit and cross-file reparent passed. Full422 Windows /
- 425 Linux tests at that checkpoint. See release-source-integration.md.
-- Direct drawing fef2e0d plus tooltip ad7feb5: OA Interaction, SA Functional and
-  Boundary Exchange by palette click-click or drag; compatible highlights, automatic
-  function ports, four-side draggable anchors, contextual menus and source folders.
-  Independent pointer/tooltip findings fixed and native retested. Windows193 desktop
-  and Linux189+4 focused tests followed earlier full485/488 suites. Scoped native
-  Windows/Linux acceptance: release-port-drawing.md and release-context-menus.md.
+Root is sole native operator; authorization persists. Isolated loopback test server
+20984 at127.0.0.1:8787 uses Temp/capella2-hosted-native-20260906/store, resource
+d28b2fc9-fbbd-456b-8ba8-a1195d1c8f33 revision6. No desktop trial is currently active.
+Original Capella remains available; re-inventory native windows before input.
 
-## Newly accepted state workspace
-
-Production316dc55 includes typed machine views, shared persisted geometry, atomic
-region/symbol/state creation, group movement, direct transitions and reconnection,
-Internal rows, Local edges, typed detail forms, folding, placement and navigation.
-Architecture and Behavior view selections are separate. Drafts survive rejected
-source/model commits; passive camera events never apply a form.
-
-Independent/native findings fixed: covered GPU shapes, pseudo-label/edge collision,
-selection-relayout drag displacement, missing typed form access, folded-content
-access, wrong-view placement Apply, and camera/tool leakage on machine navigation.
-An actual owner/view change resets gesture state and fits; returning to the same
-view preserves camera/tool. Exact evidence and limitations: release-state-editing.md.
-
-Verification: full551 Windows /554 Linux workspace tests and strict workspace
-Clippy at e0b2210. Final316dc55:241 desktop tests, strict all-target desktop Clippy,
-and desktop builds on each platform; five new navigation tests included. Two guide
-tests passed after help changes. Source/reST/API state contracts and actual HTTP
-rejection/revision/source/restart tests passed earlier in the integration.
-
-Root and independent Windows native trials covered1440x900 and1100x700 creation,
-nested movement, first-drag transition, endpoint/menu reconnect, invalid target,
-Escape, timed Internal, Local/EntryPoint, placement Apply, Undo/Redo and save/reopen.
-Linux native covered1440x900 creation, first transition/move, Undo/Redo, fold and
-saved collapsed reopen. Final316dc55 native on both platforms proved same-view
-camera/tool preservation and different-machine Fit/Select reset. Logs are empty.
-
-## Active R6 implementation and next actions
-
-Checkout D:/CodexBuilds/Capella2-data-integration; branch
-codex/data-contract-integration, base5ce3eef+plan2bf4c54+navigation9118218.
-Dedicated target D:/CodexBuilds/Capella2-data-target. Contract freeze is schema/source4
-with full data payload and dictionary slices together; existing typed ports remain.
-See release-data-implementation.md and release-data-contract.md in that checkout.
-
-Ownership: data_core owns core model/data/validation/references/ports/transitions
-and non-source tests; state_architecture_review owns source/migration/persistence
-and their tests; drawing_correctness owns desktop. Root owns API/OpenAPI/reST,
-integration and native input. Do not edit workers' files or reset their changes.
-
-1. Commit state evidence and fast-forward main from ad7feb5; coordinate Git index
-   before carrying documentation into the active R6 checkout.
-2. Finish R6 core/source/desktop, integrate actual REST/schema/reST, independent
-   semantic/correctness/UX review, Windows/Linux checks and real data authoring.
-3. Implement R3 typed semantic drift/reconciliation after R6 freezes. Current
-   baselines/reconciliation only cover prose. Prefer historical typed-body snapshots
-   and finite proposals; avoid a duplicate recursive semantic schema without evidence.
-4. Complete direct scenario/process gestures, persistent coverage/filters,
-   Home/recent/recovery, hosted desktop ETag workflows and offline guidance.
-5. Fresh final requirements/domain/correctness/native UX/architecture review; full
-   Windows/Linux/MSRV checks, real runtime, reproducible docs and release packaging.
-
-## Environment and native ownership
-
-Root exclusively owns native input. Latest saved Windows trial is window1706782,
-ui-state-navigation-windows,49objects/28links/1 expected missing-owner warning.
-Linux navigation trial3148598 closed normally, exec46107 exit0; baseline Linux
-trial721472 also closed normally, exec72680 exit0. Independent Windows3672536 is
-saved at1100x700. Older root drawing windows are saved. Re-inventory before input.
-Protected user7210312/6228978 were absent; do not reset/save/close if they return.
-
-Evidence: D:/CodexBuilds/Capella2-release1-01a06e2e. State source checkout/target:
-D:/CodexBuilds/Capella2-state-integration and -target. Linux source/target:
-D:/CodexBuilds/Capella2-state-linux-review and -target. Use distinct Cargo targets
-per checkout; shared-cache results were previously caught and excluded.
-
-Windows: cargo test --locked --workspace; cargo clippy --locked --workspace
---all-targets -- -D warnings; cargo build --locked -p oa-desktop -p oa-server.
-WSL Ubuntu24.04 uses target/linux-cargo.toml and Mesa software Vulkan for native
-WSLg. No remote push or usage reset authorized. No broad recursive target deletion.
+Linux is WSL Ubuntu-24.04, not the separate unconfigured Ubuntu distro. Optional
+X11 needs libxkbcommon-x11-0 and the user's sudo password; the user already has the
+exact apt command. Wayland/Windows/REST work is not blocked. Do not bypass auth.
+No remote push, usage reset or broad target cleanup authorized.