Files
ARCADIA-Studio/harness/experiments/traceability-view-17f1f89-20260923/failed-native/baseline/native-plan.md
T

28 lines
7.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# #31 native preparation proposal — preliminary validation only
Scratch only, 2026-09-23. No GUI, compiler or final staging run. Preliminary B and reserved-UUID P checks with the preserved b868541 attachment_snapshot passed (exit0, empty stderr, unchanged inputs); receipts and canonical Projects are in ../traceability-view-fixture-exploration-20260923. This is not final same-pin admission: parent must revalidate with the final candidate evaluator before freezing this fixture/catalog. Any validation repair happens before native input and is recorded; never adapt expectations to observed GUI edits.
`baseline.draft.json` is a compact typed Project assembled from the already validated #23 baseline's exact OA Activity, SA Function, typed FunctionOutput/Input port, Interaction, FunctionalExchange and Diagram record shapes. Unrelated State model records were removed, all retained references remapped to stable prefix `ea202923-0031-4000-8000-`, and two ordinary Refinement traces added using the actual Trace shape in `oa-core/tests/workflows.rs:32` and `attachment_trace_ports.rs:35`. The preliminary core checks passed without fixture repair; its draft filename remains until final same-pin admission.
IDs: project1; OA activities10/11 (“OA send”, “OA receive”); SA functions50/51 (“SA send”, “SA receive”); typed SA ports52/53; Interaction20; FunctionalExchange54 (as copied from source fixture); traces70=(10→50),71=(11→51). View100 (“01 Traceability trial”) has10,11,50 placed; view200 is an independently identified reference with10,11,50,51 placed. Both are Traceability, unrestricted filters, no hidden edges or authored routes. Placement aliases are deliberately fixture-specific so the new default alias `view_sa_receive` is unused.
Predeclared native operation: Add existing → see **SA receive** in the initial All compatible types list → choose it → target world **(500,350)**, with a fixed maximum absolute error **1 world unit per axis**. Existing SA send is at(100,350); OA pair is at(100,100)/(500,100), so this places the counterpart on the SA row beneath its OA peer. This small 2×2 acceptance box is meaningful geometry, not arbitrary fit-to-output. Determine canvas origin/zoom/pan (or equivalent calibration from known fixture coordinates), physical-pixel scale and integer screen target *before* clicking; retain the calculation/capture. If calibration uncertainty exceeds the fixed bound, zoom/recalibrate before input. Do not enlarge the bound after seeing saved output. The command retains its passed point; bend snapping does not apply.
Source basis: ordinary canvas `diagram.rs:337–341` computes `(local-pan)/zoom`; the placement press passes that unsnapped world point (`:872` onward). Toolbar `views.rs:421–423` offers multiplicative ± zoom and a rounded percentage, not exact zoom/pan numeric entry. An arbitrary Fit transform therefore need not map(500,350) onto an integer physical pixel. Ideal nearest-pixel targeting contributes at most `0.5/(physical_pixels_per_logical_pixel * zoom)` world units per axis, before calibration and f32 rounding. The fixed 1-unit bound is a preregistered assay precision allowance, not a claim that every fit/scale can satisfy it; native targeting must establish that before input.
Predeclared visual facts to validate through core projection before freeze: view100 baseline has one visible trace70 plus ordinary Interaction20; trace71 lacks SA51's owner placement. After placement: two visible traces70/71 plus both ordinary relations20/54. Reference view200 remains independently unchanged. The explanatory UI should make clear why this differs from All relationships and why missing placement matters. Inspect the new trace's Properties without changing it; preserve the originating mixed view during the intended navigation actions.
## Full-Project oracle with a narrowly bound fresh identity
`placed-node.contract.json` declares all new Node fields except its random UUID and the two finite position coordinates bounded above: element51, alias `view_sa_receive`, size224×94, collapsed=false, empty port_anchors (serialized omission if standard serializer omits empty field). This is taken from actual `Project::place` at model.rs1962–1986 and fresh_alias at1783–1814. No semantic record may be created/changed.
Before launch freeze canonical baseline **B** using attachment_snapshot, and construct **P(UUID)** by cloning all of B and adding exactly the declared Node to view100. Canonicalize the known optional-empty field shape through the same-pin evaluator *before* launch using a reserved validation-only UUID, so serializer omission is not an after-the-fact allowance. Validate P as a complete Project. Store the contract and hashes in the immutable manifest.
At the first P checkpoint, a small extension to the existing check.py may extract the set difference of **Node IDs in view100 only**. Require exactly one new UUIDv4, absent from every baseline identity, used both as map key and Node.id. Require finite x,y with abs(x-500)<=1 and abs(y-350)<=1. Substitute **only** this UUID and these two checked position values into the frozen P(UUID,x,y), then compare the **entire** actual Project against it. Only after full equality succeeds create-new `fresh-node-binding.json` recording UUID, exact accepted x/y numbers, fixed position rule, baseline/catalog/manifest/executable/input hashes and first checkpoint receipt. Do not bind on failure. Every later P (Redo/reopen) requires that same immutable identity and exact numeric coordinates, with no further tolerance. B checkpoints require exact original full Project and absence of that node. Never ignore IDs globally, strip fields, allow extra keys, round/normalize coordinates, or learn alias/size/other fields from actual output. Report the actual accepted coordinates and signed differences from target transparently.
Fixed native flow: open staged `working/import.json`, then Save As `working/traceability.arcadia` **before the first B check**. The saved source path is predeclared and absent at stage creation; final reopen uses this saved source. Record file-dialog actions and complete saved-source snapshots. B open/save; inspect View visibility to read missing-SA-endpoint reason for trace71, leaving B unchanged; P place; B Undo; P Redo; P select trace/inspect; P reference view; normal close; fresh process reopen/save P. Capture initial chooser (SA receive visible without manually changing filter), explanation, baseline omission reason and after-placement shown state, menu/selection navigation, source save and final reopened view. Full Project evaluator accepts either JSON or source. No extra trace or filter mutation is needed for native omission-reason observation; existing automated tests cover ordinary-exchange Hide/category exclusion and port-owner trace geometry. Those ordinary-exchange tests are not specific hidden-trace tests. Exchange-trace semantic validity is tested; graphical omission of relation-endpoint traces is derived from projector source, not directly asserted by those tests.
## Reuse, not another harness
Use #23 stage.py admission checks, artifact relocation, private profile/unrelated cwd, child-only environment, create-new numbered launch observer, capture metadata and complete-Project check.py as the base. Update source pin/fixtures/catalog and add only the one-time fresh-node binding. Exclude the #23 routing probe/arithmetic expectations: no new router oracle is needed. Same-pin attachment_snapshot validates B and reserved-UUID P, snapshots saved checkpoints, and remains read-only/create_new. Final manifest must bind baseline, contract, scripts, gate receipts, GUI/evaluator/runtime and preserved artifact paths; no live shared target binary bindings. No final staging records, native acceptance records or execution receipts are created by this preparation.