ARCADIA-Studio/harness/TASK_LEDGER.md

Task Ledger — first release

Authoritative objective: attachment07aee762-7d27-4cbe-81c3-2e82c7170711/goal-objective.md, read fully on2026-09-05. STATE.md records execution evidence; PLAN.md is the living strategy; DECISIONS.md and linked release contracts retain detailed rationale.

Goal and success criteria

System engineers can develop a coherent OA→SA system model, including iterative changes and evidence, through equivalent graphical, textual and REST workflows. Rust/Iced Windows and Linux release, strict reST semantics, navigable offline concepts/tutorials, and reproducible build/run/evaluation instructions. Later Arcadia layers are future releases. Completion requires actual native workflows, automated invariants, and fresh cross-disciplinary acceptance, not compilation or a feature count.

Given facts

• User prioritizes engineering usability and Capella domain fidelity, hierarchical containment/allocation displays, real function/component ports and intuitive transitions in both directions.
• Text-only model development must be practical; modular files/includes are the proposed answer to the current huge flat file.
• Drag selection must remain stable; behavior/scenario canvases must support direct editing consistent with architecture.
• Git and worktrees are authorized. Remote publication is not requested.
• Connection routes need explicit bend points/customization or sufficiently effective automatic routing. User observed straight connections prevent readable diagrams. Treat saved per-diagram routes and practical obstacle avoidance as a primary requirement, not visual decoration.

Verified facts

• Native Capella SAB authoring creates function input/output endpoints with an FE. Component ports separately carry Standard/Flow kind, orientation, interface roles and explicit allocated function ports. Details and successfully performed versus merely observed operations are in release-capella-workflow-benchmark.md.
• Studio uses one typed Project and validated atomic commands across Rust core/desktop/server. Hierarchy projection distinguishes actual allocation from inferred parent summaries; IDs and placement are separate.
• Drag selection bug fixed and committed2ef16dc;71desktop tests and real moved-card selection/property editing passed before typed-port integration.
• Typed ports/schema3 migration merged757ab88. Existing port identities survive as Legacy and missing FE endpoints are generated deterministically; current migration and port tests provide scoped evidence in release-port-core.md/release-port-migration.md.
• Independent core review reproduced alias reservation and same-transaction allocation replacement defects; fixes have focused regression evidence. Desktop port integration has passing focused event/form tests; full checks and native acceptance are still pending.
• Current behavior diagrams derive geometry and only handle selection. Text editing currently flattens the accepted model. These remain product gaps regardless of underlying semantic coverage.

Assumptions to test

• Aggregate-oriented source files will reduce cognitive load enough for routine engineering edits; file splitting alone may leave declaration syntax too flat.
• Behavior layout can reuse NodePlacement plus typed diagram context without duplicating semantic state; reconnection/reordering must preserve existing occurrence/relation identities.
• Editable per-diagram bends plus an automatic initial route can resolve realistic crossings; an automatic layout cannot guarantee an ideal readable arrangement for arbitrary models. Test manual control, nesting, ports and persisted/exported route parity.
• Source comments and ownership can survive graphical edits by replacing only changed declaration spans. Generated IDs must stabilize before subsequent text edits.

Open questions

• Which combination of file organization, nesting syntax and navigation best supports realistic text-only engineering tasks? Independent candidate comparison is active.
• Can an engineer discover and complete typed exchange/allocation and legacy resolution workflows with acceptable effort at minimum window size? Native acceptance is pending after physical Escape.
• What remaining OA/SA gaps materially block target workflows? R3 semantic reconciliation, R6 data contracts, directly editable behavior, lifecycle/recovery and hosted editing remain in the release plan.

Candidate designs and current decisions

• Source candidate A: retain explicit source3 declarations in semantic aggregate files with includes. Candidate B: nested owner/context syntax lowering to the same model. Candidate C: independent critic to propose a materially different alternative. Rank on domain clarity, task effort, identity/roundtrip safety, Git locality and grammar/implementation complexity. Current pure bundle implementation is a testable foundation, not proof that A alone satisfies usability.
• Behavior alternatives: independent UI-only coordinates, new behavior-layout schema, or existing diagram placements with explicit context. Prefer the last candidate provisionally: it preserves text/API parity and command history without a second geometry system. Validate on direct state-machine creation/move/reconnect before extending all behavior views.
• Ports: adopted typed separation based on official metamodel plus direct native evidence; rejected generic InOut/interface port conflation and inferred allocation facts. See release-port-contract.md. Revisit only with contradictory domain evidence or concrete usability failures.

Current strategy and evaluators

Finish and independently review typed-port desktop integration; require creation/generation/split/undo/reopen invariants and native trials. In parallel, test pure source-bundle compilation/updates and independently evaluate text representations using representative engineering tasks. Then integrate per-file source editing, safe project saves and REST bundles against the selected design. Prototype persisted direct behavior gestures next. Continue remaining release semantics and cross-disciplinary acceptance; no subsystem checkpoint constitutes release completion.

Meaningful progress now: committed drag fix and native evidence, integrated typed core contracts, reproduced/fixed transaction defects, passing focused authoring tests, and a concrete source experiment. Highest uncertainty is source/behavior usability; more feature enumeration without task evidence would be a poor proxy.