Qualify owned completion-dialog handling in native save/reopen checks
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
This issue has not been assessed yet.
Description
The read-only diagnostic in #285 retained three identical completion-dialog captures while the original automation call remained pending and hit its 180-second limit. Save and reopen were not reached. The dialog is an observed lead; a causal explanation still needs a controlled check.
Scope: qualify the smallest owned, bounded completion-dialog handling step needed for this single existing saved-design cycle. Keep the mapping, input, independent XML expectations, original 180-second phase limit, process ownership, retained originals and alternate display unchanged. Preserve the completed read-only failure as separate evidence. Do not broaden this into general desktop automation or alter ferrule mapping behavior.
Acceptance:
- Bind a narrowly scoped mechanism to the exact owned application and observed completion dialog; refuse other dialogs, unrelated windows and ambiguous ownership.
- Review the mechanism independently and verify positive, refusal, timeout and cleanup cases before a fresh native attempt.
- Retain fresh original dialog observations and action/result records, proving whether the automation call returns.
- Qualify save, reopen and the second execution against both frozen output and saved-design expectations, or report the remaining failure precisely.
Depends on #285; continues #263. I own this scope.
Live window ownership, dialog handling and save/reopen remain unproved. The phase-clock observer is under review.
- 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from DeandreT/ferrule
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
test(mfd): synthetic whole-design MFD corpus with a stage-outcome ledgerPossibly taken @DeandreT claimed this today. Open
DeandreT/ferrule#1396 · 1 assignee ·
Maintainers usually reply within 1 day
-
arch: one built-in function catalog and shared limit definitionsPossibly taken @DeandreT claimed this 1 day ago. Open
DeandreT/ferrule#1390 · 1 assignee ·
Maintainers usually reply within 1 day
-
arch: type schema roles and format optionsPossibly taken @DeandreT claimed this 1 day ago. Open
DeandreT/ferrule#1389 · 1 assignee ·
Maintainers usually reply within 1 day
-
arch: remove downward dependencies on format adaptersPossibly taken @DeandreT claimed this 1 day ago. Open
DeandreT/ferrule#1388 · 1 assignee ·
Maintainers usually reply within 1 day
All issues in DeandreT/ferrule
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
madesroches/fontaine#513 ·
Maintainers usually reply within 1 day
-
area:ui needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
bherbruck/solvecraft#13497 ·
-
needs-triage tooling
Difficulty 1/5 Under an hour Newbie friendliness 90/100
neilsh/stunt-reel#317 ·
Maintainers usually reply within 1 day
-
Add Noto Sans Thaana (Dhivehi) - missing face blocking Thaana support in PdfCraftPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
storytold/craft-fonts#65 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
storytold/craft-libs#723 ·
Maintainers usually reply within 1 day