diff --git a/PROJECT_GOAL.md b/PROJECT_GOAL.md index 799056d0..bc536a56 100644 --- a/PROJECT_GOAL.md +++ b/PROJECT_GOAL.md @@ -13,6 +13,7 @@ Deliver the product described by the repository, specification, requirements, re Persist until the intended outcome is genuinely achieved. Do not stop at: + - research, - planning, - a plausible conceptual design, @@ -26,6 +27,7 @@ The final result must be conceptually coherent, technically sound, usable, imple Bias toward action and completion. Resolve discoverable questions yourself through: + - repository exploration, - web and literature research, - primary documentation, @@ -76,27 +78,35 @@ Maintain a concise durable Task Ledger in `harness/TASK_LEDGER.md`, unless an eq It should distinguish: ### Goal and success criteria + What outcome must ultimately exist. ### Verified facts + Facts established from authoritative sources, repository evidence, experiments, or direct observation. ### Given facts + Requirements or constraints explicitly supplied by me. ### Assumptions + Things currently treated as true but not yet verified. ### Open questions + Important unknowns. ### Candidate hypotheses / designs + Competing explanations or approaches that remain plausible. ### Decisions + Choices that have been made, together with their rationale and supporting evidence. ### Current strategy + The current high-level route toward the goal. Do not silently convert an assumption into a fact. @@ -179,6 +189,7 @@ Possible roles include: - integration reviewer. Give every subagent: + - one bounded question or responsibility, - relevant context, - clear boundaries, @@ -215,15 +226,19 @@ For consequential, uncertain, difficult-to-reverse design problems, do not accep Use an idea-tournament process. ### Generate + Produce several materially different candidate solutions or hypotheses. Aim for diversity rather than cosmetic variations of one idea. ### Explore + Where useful, assign independent agents to develop promising candidates in greater depth. ### Reflect + Have independent critics examine candidates for: + - correctness, - hidden assumptions, - internal consistency, @@ -238,6 +253,7 @@ Have independent critics examine candidates for: Critics should actively attempt to falsify proposals rather than merely improve them. ### Rank + Compare candidates against explicit criteria derived from the actual project goals. Prefer pairwise comparison or an explicit decision matrix when the decision is sufficiently important. @@ -245,6 +261,7 @@ Prefer pairwise comparison or an explicit decision matrix when the decision is s Do not rank based on eloquence. ### Evolve + Improve the strongest candidates. Combine complementary ideas when a hybrid is genuinely better. @@ -252,6 +269,7 @@ 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. @@ -456,6 +474,7 @@ Do not equate technical functionality with usability. Use independent reviewers throughout the project, but select reviewers according to the artifact being evaluated. A conceptual or semantic design may need: + - domain review, - consistency review, - adversarial / falsification review, @@ -463,6 +482,7 @@ A conceptual or semantic design may need: - and user-workflow review. A language may need: + - ambiguity review, - grammar / round-trip review, - human-editability review, @@ -470,6 +490,7 @@ A language may need: - and version-control review. An implementation may need: + - correctness review, - architecture review, - requirements review, @@ -481,6 +502,7 @@ A final release should receive a cross-disciplinary review rather than only a co Require concrete findings and evidence. For material findings: + 1. verify the finding, 2. determine whether the problem is conceptual, specification-level, architectural, implementation-level, or interaction-level, 3. fix it at the correct layer, @@ -562,11 +584,11 @@ Do not automatically use maximum reasoning for every delegated task. Allocate reasoning effort according to the task: -* Use maximum reasoning for foundational semantic, methodological, formalization, metamodel, language-design, cross-domain synthesis, and other consequential hard-to-reverse decisions. -* Use 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. +- 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. @@ -578,12 +600,18 @@ Use GPT-6 Astra model exclusively. ## 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. @@ -591,33 +619,52 @@ Keep in mind that the target audience for the application are system engineers. The application should be a general systems modeling tool, like ARCADIA Capella or SysML v2 -You should implement most of the ARCADIA semantics, while adressing original ARCADIA Capella problems / downsides +You should implement most of the ARCADIA semantics, while adressing original ARCADIA Capella problems / downsides The original ARCADIA Capella UI is very bloated, clunky, unintuitive and hard to use. In addition, it lacks a number of quality of life features. You should at all cost avoid making the same mistakes as the developers of the original ARCADIA Capella You should explore the functionality & UI of the original ARCADIA Capella to take the most useful and powerful ideas from it. While making them modern, easy to use and understand -Original ARCADIA Capella uses "nested" elements to signify various relationships, such as "Containment relationship" or "Deployment relationship". Instead of using visually noisy arrows / graph edges. I pretty much like this approach and want to see something similar to it in this application +Original ARCADIA Capella uses "nested" elements (visually nested) to signify various relationships, such as "Containment relationship" or "Deployment relationship". Instead of using visually noisy arrows / graph edges. I pretty much like this approach and want to see something similar to it in this application To explore the original ARCADIA Capella UI & semantics you may use web resources / web search / official and community docs. Or open the original ARCADIA Capella installed on this desktop machine for exploration -Your second, parallel goal is to create a textual representation for ARCADIA, similar to SysML v2. So a user can either edit a system model using UI (graphical representation) or text. Both graphical and textual representations should be fully equivalent and have full parity. You may take inspiration from SysML v2. Both graphical and textual representations should have one overarching, concrete, unambiguous spec in reST format, similar to SysML v2 strictness -The application should support both forms of editing -The 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 +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 -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 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 +@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. + +### 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 +Right now, the behavior & scenarios UI is hard to use. It contains static / uneditable diagrams, which is highly dubious. In addition, user workflow with the behavior & scenarios UI differ significantly from the other UIs - you can't edit diagrams and instead suppose to click on menus for model development ---- +--- -The current project state is nowhere near the usability of the original ARCADIA Capella (despite its downfalls) or its functionality / semantics. You should focus on that by studying original ARCADIA Capella very closely and implementing its features in a modern, ergonomic and easy to use way +The current project state is nowhere near the usability of the original ARCADIA Capella (despite its downfalls) or its functionality / semantics. You should focus on that by studying original ARCADIA Capella very closely and implementing its features in a modern, ergonomic and easy to use way \ No newline at end of file diff --git a/harness/STATE.md b/harness/STATE.md index 83735cb5..79f53e88 100644 --- a/harness/STATE.md +++ b/harness/STATE.md @@ -2,6 +2,23 @@ ## Active continuation — 2026-09-10 +Latest checkpoint: read updated objective attachment `578cf63e-08b7-411f-a01e-20416441d5e2` +fully and updated `PROJECT_GOAL.md`. Its emphasis on Capella-level useful modeling +and usability keeps behavior authoring central. Packaging is committed `b98f135`; +current product/release acceptance remains incomplete. First merged desktop +artifact finished **615/618 passed**, with three concrete failures assigned; +the previous running status below is historical. Full evidence and diagnosis: +`release-integrated-gates-20260910.md`. + +Current leases: behavior_audit owns scenario workspace/B3 corrections and sole +Cargo compilation; release_audit now owns only new behavior/creation.rs/tests +pending coordinated shared wiring, with packaging frozen; palette_finish owns +exclusive native input for a bounded Capella behavior-creation study. Root does +not operate native UI until that lease returns. Candidate 2 closed cleanly after +F2 equality and saved Actor checkpoint; no process 648 remains. Root owns merges, +specification checks and ledgers. Other host owns remaining typed-history seed +fix, standalone scenario lifetimes and its own native scenario contract. + Integration update (2026-09-10): local branch is `codex/release1-9e8r6t`. Palette `7d1df4f` is published separately. Received Codex-956atf's exact Git bundle (57,658 bytes, SHA256 `85A38B00207036DCB8DB24ED4A7E80B2BE670275EEB7B00413D36153322ADA5D`), diff --git a/harness/TASK_LEDGER.md b/harness/TASK_LEDGER.md index 0995a467..e984d923 100644 --- a/harness/TASK_LEDGER.md +++ b/harness/TASK_LEDGER.md @@ -1,5 +1,29 @@ # Task Ledger — first release +## Updated objective and current strategy — 2026-09-10 + +Given: the latest authoritative request is +`578cf63e-08b7-411f-a01e-20416441d5e2/goal-objective.md`, copied into +`PROJECT_GOAL.md`. It preserves complete OA/SA, parity, API, traceability, +cross-platform and review requirements, and explicitly emphasizes that current +usability/functionality remains below Capella. The next changes must address +actual engineer workflows; passing narrow technical checks is insufficient. + +Verified: palette F2/Save/Undo/Redo and the exact Entity source oracle passed +on candidate 2. Named Actor placement is saved; full basic workflow is pending. +Merged desktop ran 618 tests: 615 passed and 3 failed, with concrete navigation +and history-seed causes now assigned. Schema fixtures and strict reST rendering +passed. Packaging is committed with independent review and exact notice bytes. +See `release-integrated-gates-20260910.md` for scope and failures. + +Strategy: finish the actual remaining-height scenario workspace, repair its +navigation and typed-history failures, and make starting a named behavior local +with explicit viewpoint/owner choices. An independent native Capella study +informs that workflow while the creation worker implements its isolated module. +Root integrates and then evaluates realistic current-build tasks. Assumption: +these changes will reduce navigation/draft detours; native acceptance must prove +that. Linux runtime and broader parity/release gates remain unresolved. + **18:10 UTC checkpoint, 2026-09-10:** palette repair candidate 2 passes focused tests/build/format/strict Clippy and native recovered-draft Escape/save plus the complete Entity source oracle. The user stopped Computer Use; native verification diff --git a/harness/release-integrated-gates-20260910.md b/harness/release-integrated-gates-20260910.md new file mode 100644 index 00000000..77d5cb86 --- /dev/null +++ b/harness/release-integrated-gates-20260910.md @@ -0,0 +1,61 @@ +# Integrated checks — 2026-09-10 + +Root identity: Codex-9e8r6t. These are intermediate results, not release acceptance. + +## First merged desktop artifact + +Source: merge `057eddd` plus the checkpoint autofocus patch later committed in +`31b7dc3`. The Rust sources were frozen throughout compilation. After the 13 +checkpoint tests passed, root copied the built test executable and matching +libunwind into `.local/integration-20260910/tests-057eddd/`; later source edits +could not change this running artifact. SHA256: +`D504C59BC2A5853F4FBE54A9DFA841DA0AC8DD2475342E45A91DBAA6533372B4`. +The exact additional source patch and execution metadata are retained there. + +Full inventory execution ran from 18:21:36 to 18:29:26 UTC, 469.21 test seconds, +and exited 101: **615 passed, 3 failed, 0 ignored**. Failures: + +- Scenario return after rename/deletion/retarget: selected identity differed + from the asserted caller/use or still-open scenario. The layout worker found + that generic retarget commands can leave a cross-owner selection, and a + same-ID selection shortcut can skip changing the active scenario on successful + Back. A narrow correction and stronger active-scenario assertion are in the + next candidate; they have not yet passed. +- Both exhaustive stored-history choice and exact-string tests failed with + UUID parsing of `NotApplicable`. Root found `seed()` using permissive shape + matching to identify that enum, so nullable UUID/string branches receive the + literal instead of null. The other host's forms owner is correcting explicit + enum admission while preserving raw invalid-input editing. + +This artifact predates nullable constructor-cache fix `b6b76ef`, merged locally +in `a70de55`, and the later scenario workspace. That cache fix is distinct from +the seed defect. Gitea issue 1 comments 68–69 carry the failures and diagnosis. +No assertions were weakened or failed checks reported as acceptance. + +## Specification check + +On merged source, `semantic_schema.py --check --validate` passed **72 fixtures**, +**204 schemas**, **14 families** and **90 scalar leaves** using the retained +local jsonschema dependency directory. The first invocation with the bundled +Python alone lacked jsonschema; setting its task-local PYTHONPATH resolved that +environment issue without changing the script or dependencies. + +Docutils 0.22.2 rendered both `docs/language.rst` and `docs/api.rst` under +`--strict`, with no warnings. API HTML was byte-identical. Language HTML was +identical after newline normalization: the Git checkout has LF and the Windows +renderer produced 2,776 CRLF lines. The rendered files remain under the local +integration directory. This establishes specification/render synchronization, +not full graphical/textual/REST runtime parity. + +## Packaging integration + +Commit `b98f135` includes the independently reviewed packaging changes. Root +explicitly renormalized the two Fira notices after applying their exact `-text` +attributes. The three upstream notice exceptions retain intentional original +whitespace; all other staged files passed the whitespace check. Raw and staged +bytes of all three checksum-bound notices were independently compared exactly +in `.local/packaging-20260910/root-staged-verbatim-notices.json`. The author's +separate alternate-index check covers all 25 referenced notice files through +checkout. Native Linux, a real Linux desktop/server archive, container execution +and final optimized packages remain open gates. See the packaging reports for +the explicit synthetic/full-graph versus real-Windows evidence distinction. diff --git a/harness/release-palette-native-20260910.md b/harness/release-palette-native-20260910.md index d67116ed..fc5886b6 100644 --- a/harness/release-palette-native-20260910.md +++ b/harness/release-palette-native-20260910.md @@ -139,3 +139,30 @@ that state; explicit refocus and a second type_text produced the intended name. The cause is not established, so this is not recorded as a proven application typing defect or as uninterrupted first-attempt typing. Applying, history and source persistence were tested only after the correct text was visible. + +## Actor continuation and clean close + +Continued the ordinary root-creation sequence at 1442×932 outer size. Four minus +steps changed the 150% overview to approximately 72%; camera translation and +the existing Entity's world placement remained stable. Compact Actor tool, +blank point (817,440), `Control centre`, Enter created the Actor at that point. +The actual placement property values were approximately (680.1408,120.8218), +consistent with the fractional zoom. As the independent contract requires, +the operator explicitly set X=680 and Y=120 in Placement properties and applied. +Ctrl+S saved successfully, and `checkpoint-actor` preserves the complete bundle. +Its Actor ID is `b3cd865b-b1df-43b4-9396-2e4aaec65367`, placement ID +`ee9a090c-b322-4e37-b6d4-40e2a1af725f`. The complete `basic` oracle is still +pending the Activity, existing placement, allocation, Interaction and rename. +No complete Actor-only model oracle is claimed from the property inspection. + +One attempted Y replacement appended text after a multi-click selection. The +operator observed it, explicitly selected all and cleared, then entered `120`; +only the visibly correct X/Y values were applied. User input interrupted one +typing attempt; root reobserved before continuing. These automation observations +remain distinct from a demonstrated application defect. + +The candidate closed through its title-bar button with all changes saved. +The subsequent process query found process 648 absent; stderr was empty. Root +transferred the exclusive native-input lease to the independent Capella creation +workflow investigator. A future current-build session can resume from the whole +`checkpoint-actor` directory without redoing earlier accepted fixture creation.