Qualify native saved-design reopen and second-save checkpoint

Open
#263 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

This issue has not been assessed yet.

Description

The private native helper opens, executes, saves and closes a staged design, but does not reopen, execute or save it again. Saved-file inspection records no native replay.

Qualify one bounded cycle using an already admitted, independently owned existing design:

  1. Open → execute → save → close.
  2. Reopen the exact saved design → execute → save2 → close.

Acceptance:

  • Freeze the complete design, schema/resource siblings, inputs and independent expected outputs before either execution. Preserve the first saved design and use a separate absent save2 destination.
  • Retain both complete execution outputs, messages/errors, saved artifacts and source/input body guards before comparisons. Check saved connections, parameter order and identities with an explicit ID mapping where necessary; equal output alone is insufficient.
  • Qualify the cycle on alternate display :109 with the existing bounded owner, observed dialog handling and closure controls. Distinguish application exit from owned helper cleanup, and retain timeouts, missing save/reopen files and failed executions without replacing evidence.
  • Publish a focused neutral protocol/report at docs/conformance/native-saved-design-reopen.md; keep application-specific controller code, paths, installation and activation details private.

Dependencies and limits:

  • Root must provide an individually admitted existing owned design and fresh application/tool/display/owner bindings before execution. No valid filter/map seed is assumed.
  • This qualifies the missing controller checkpoint. Creating a native representation for #203 case 7, widening to its 17 filter/map recipes, import/export implementation, #203 fixture changes, #253 internal engine observations and #261 guide work remain separate.
  • Preserve existing controller confinement, failure categories and deadlines. No engine/model/backend/GUI policy changes, generic lifecycle framework or parity claim.

The first real phase timed out at the unchanged 180-second deadline with complete-profile-matching partial output. It reached no successful result, Saved1, reopen or Saved2. #285 isolates the unknown stall; complete originals and owned-process closure were independently reviewed.

The neutral protocol/report is in PR #287. Native save/reopen remains unqualified; no parity is claimed.

Dominant language
Rust
Stars
1
Forks
0
Avg merge
2h 50m
Merged PRs (30d)
571

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DeandreT/ferrule

All issues in DeandreT/ferrule

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.