Conversation
There was a problem hiding this comment.
Pull request overview
Adds a detailed implementation plan (RowProcessGraph.md) for a new row-process graph editing model for ARCtrl, defining types, API, grouping/editing semantics, and a phased implementation sequence.
Changes:
- Introduces a comprehensive spec for treating each physical
ArcTablerow as a process-row with IO-name-based connectivity - Defines public Fable-safe API surface, error model, grouping engine, and source-row materialization helpers
- Lays out a 10-phase implementation sequence with acceptance criteria
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| Create a Fable-compatible intermediate editing model for `ArcInvestigation` that: | ||
|
|
||
| - preserves `ArcTable` roundtrip fidelity, | ||
| - treats each physical table row as one editable process-row, |
There was a problem hiding this comment.
If you want to align with ISA processes, you can unify a lot of information by not making each row a row, but instead use connected nodes. Exmp. If you have 10 different inputs, each with the same organism, they can all map to that organism node. So i think the rows can designed more flexible. There was an approach to this done by oliver and timo, in which they designed some triplet type using Header type, header info and value.
There was a problem hiding this comment.
This also has the added benefit to better support fan-in/fan-out as the focus on input/output has more weight
There was a problem hiding this comment.
i thought about that but wanted to keep full flexibility for editing if needed. that's why i chose to do it like this
There was a problem hiding this comment.
I do not see what flexibility we loose with the approach i suggested?
| - avoid .NET-specific interfaces in the public surface | ||
| - Internal implementation may use mutable dictionaries and caches | ||
| - Row order must remain stable and reflect original physical table order | ||
| - The model is editor-oriented and should expose renderer-friendly row/table views |
There was a problem hiding this comment.
This step is not required. Instead i would recommend it should have "lazy read features" or "performant access"
| Out of scope for v2: | ||
|
|
||
| - replacing existing `ProcessSequence` conversion APIs | ||
| - persistent UI state or rendering logic |
There was a problem hiding this comment.
UI and rendering are part of ARCitect and existing conversions shouldn't be replaced since this is added on top
There was a problem hiding this comment.
ARCtrl should not have anything related to UI?
EDIT: I mean currently, so is this just here to tell the agent "nono! ui will be somewhere else"?
|
|
||
| ## 4) Locked Decisions | ||
|
|
||
| - Canonical unit: `1 row = 1 process-row` |
| ## 4) Locked Decisions | ||
|
|
||
| - Canonical unit: `1 row = 1 process-row` | ||
| - Physical row order is semantically relevant for editor presentation and must stay stable |
There was a problem hiding this comment.
not sure for this feature,
There was a problem hiding this comment.
if people use this to edit their tables it could be irritating if rows start to swap as soon as something is added
There was a problem hiding this comment.
I think if people use this editor this can be expected. Depending on the changes it will kill sorting anyways. IN UI we can add a warning "This action will make changes to the following tables: ... -> Confirm?"
There was a problem hiding this comment.
but if we can prevent it, wouldn't it be better?
| - assign new output names to those new rows | ||
| - allow branching inside an existing table or into another target table | ||
| - the source rows may already have outputs, or may currently have no output at all | ||
|
|
There was a problem hiding this comment.
maybe add: quickly create new table flows (multiple tables. setting param/chara/factor/component then expanding on inputs and outputs for the freshly created flow)
|
|
||
| ### 6.1 Row Model | ||
|
|
||
| - Each included physical row becomes one row node |
There was a problem hiding this comment.
so each row-node is only one table, and these row nodes are connected via input/output? in think the idea of having process node triplets that each store container and table source without replicated copies is something i prefer more.
Summary
Adds
RowProcessGraph.md, a detailed implementation plan for a new row-process graph editing model for ARCtrl.The plan describes a Fable-compatible intermediate type for editing
ArcInvestigationtables while preserving roundtrip fidelity. It treats each physical table row as one process-row, derives connectivity from IO name equality, supports lineage-aware grouping, and keeps row order stable.Planned Capabilities
API Direction
The plan defines:
Notes
This is a plan/spec only. It does not yet implement the row-process graph.