From 1c3c55c6aaefc8e88992eb7d031ceeb6922b7223 Mon Sep 17 00:00:00 2001 From: Happy Mahlangu Date: Tue, 18 Aug 2026 13:25:29 +0200 Subject: [PATCH] fix(examples): stop claiming a guessed selector is a flagged TODO MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit purchase-info-records-report.flow.yaml's header said two steps were left as flagged TODOs rather than guessed, but only one was — the tile-navigation step carried a resolved selector with its own comment admitting it was "a best-effort guess... not a confirmed label," directly contradicting the header. The step is now an honest, unresolved TODO matching its sibling's shape, and a permanent test parses the whole file so this can't silently regress. Fixes #490 --- crates/flowproof-cli/tests/examples_resolve.rs | 17 +++++++++++++++++ .../purchase-info-records-report.flow.yaml | 4 +--- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/crates/flowproof-cli/tests/examples_resolve.rs b/crates/flowproof-cli/tests/examples_resolve.rs index 69246771..95d4b700 100644 --- a/crates/flowproof-cli/tests/examples_resolve.rs +++ b/crates/flowproof-cli/tests/examples_resolve.rs @@ -6,6 +6,8 @@ use flowproof_agent::{FlowSpec, SuiteManifest}; const FIORI_SPEC: &str = include_str!("../../../examples/fiori/manage-info-records.flow.yaml"); +const PURCHASE_INFO_RECORDS_SPEC: &str = + include_str!("../../../examples/fiori/purchase-info-records-report.flow.yaml"); const FIORI_SUITE: &str = include_str!("../../../examples/fiori/suite.yaml"); const CONN_TEST_SPEC: &str = include_str!("../../../examples/api/connection-test.flow.yaml"); /// The npm-path agent quickstart. It is the first example a reader coming @@ -65,6 +67,21 @@ fn fiori_example_resolves_entirely_via_rules() { } } +/// Unlike `fiori_example_resolves_entirely_via_rules`, this example's header +/// deliberately promises two flagged TODOs left unresolved for `flowproof +/// record` to fill in against the live screen, not guessed here — so this +/// test only proves the file parses, and does not run every step through +/// `rules::resolve_step` (the two TODO steps are plain prose by design and +/// are not expected to resolve). +#[test] +fn purchase_info_records_example_parses_as_a_multi_surface_flow() { + let spec = FlowSpec::parse(PURCHASE_INFO_RECORDS_SPEC).expect("example parses"); + assert!( + spec.apps.contains_key("fiori") && spec.apps.contains_key("excel"), + "flow declares both the fiori and excel surfaces" + ); +} + #[test] fn fiori_suite_manifest_declares_the_data_leg() { let manifest: SuiteManifest = serde_yaml::from_str(FIORI_SUITE).expect("suite.yaml parses"); diff --git a/examples/fiori/purchase-info-records-report.flow.yaml b/examples/fiori/purchase-info-records-report.flow.yaml index 586ed773..7a42d0e4 100644 --- a/examples/fiori/purchase-info-records-report.flow.yaml +++ b/examples/fiori/purchase-info-records-report.flow.yaml @@ -49,9 +49,7 @@ steps: # single clear target ("Manage Info Records" / "Display purchasing # info records by Supplier" / "Display purchasing info records by # material") — resolve against the live tile catalog at record time. - # This is a best-effort guess at the tile's visible text, not a - # confirmed label. - - Click "Display Purchasing Info Record" + - resolve the tile to click against the live catalog — no single clear target is named. Observed - the PDF's Step 3 lists three near-identical options — "Manage Info Records", "Display purchasing info records by Supplier", "Display purchasing info records by material". - assert: page shows Info Record # -- Search the standard info record by the minted test data -------