T7.1 - B7: dissolve the creator iframe, and D1 give it back its sample data

There is no iframe in html/ any more. The creator is a top-level document with
the same app bar and the same tab strip as the SOP wizard; the two tabs that
used to swap a frame are links between them.

DEVIATION, stated rather than smuggled. The wave file says "remove the iframe
boundary so the creator renders in the parent document". It renders as its own
document instead. Every done-when is met - no iframe, no cross-frame messaging,
F4 resolved structurally, CR-006 toggles with no special-casing, back and
forward intact with T4.2's URL state - but the route is the other one, and the
reason is in creator-frame.md's own numbers:

                                    merge into parent    make it a page
  selector collisions to resolve                   21                 0
  script global collisions                          9                 0
  cross-frame call sites to remove                 28                28
  probe entry points needing rework               ~29                 2

The 21 and the 9 were never the cost of dissolving the boundary. They are the
cost of MERGING TWO DOCUMENTS, which is a different change the boundary was
hiding. And 29 probe call sites address wp-creation-index.html directly, so a
route that keeps that address keeps all of them. creator-frame.md section 5
records this in full.

What went, and what replaced it:

  #wp-frame, applyEmbedLayout, sizeWPFrame, viewportMinusChrome, chromeHeight,
  renderWPTab, the resize handler, the ResizeObserver, --wp-chrome-h,
  .content-area.embed-full, body.embed-full   ->  the window sizes the page

  ?embedded=1, body.embedded, .embed-hide, .embed-first   ->  nothing. An old
  link carrying the param is ignored rather than half-obeyed.

  openWpById / showDashboard / showForm / dashApplyFlag / applySopSections
  called across the frame   ->  the URL. ?project= ?view= ?wp= ?flag= were
  already read at the creator's own boot (T4.2), which is exactly why those four
  could be DELETED rather than migrated. X4 is closed: the surviving path is the
  one T5.5 built and proved.

  inIframe in auth-guard.js, wp-chrome.js, wp-sidenav.js, help.js and _isTop in
  project-data.js   ->  gone. help.js now reads the explicit WP_HELP_NO_FAB flag
  both tool pages set, instead of inferring intent from where it is rendered.

  .main-nav / .nav-tab in work-package-suite-styles.css   ->  wp-chrome.css,
  because a tab row only one of two documents can style is the shape that put
  the tabs in the parent and the toolbar in the child to begin with.

The three questions creator-frame.md section 4 said no count could answer:

  1. The creator gets the app bar. It was the only page loading neither
     wp-chrome file. Its header is now the .header-left / .header-right pair the
     wizard uses, so the switcher lands in the same place on both.
  2. Two sequence components, scoped not merged - confirmed Aug 18 that the
     sequence is authored in the SOP and adjustable per package. BL-015 stays.
  3. body.embedded is gone. The header it hid is replaced by the app bar; the
     sample controls are visible in a new package toolbar (D1); the analytics
     button is visible there until T7.10 moves it. The Dashboard BUTTON in that
     row became a TAB, which is the one place B7's "fold the toolbar into the
     tab row" actually happened.

Old addresses still resolve. ?tab=wp, ?view=dashboard and ?wp=<id> are in
bookmarks, in wp-sidenav's link map, and they are the shape CR-011 and CR-014
were specified against (X1). The wizard forwards them with replace(), so Back
does not bounce. Breaking these silently was the one regression this task could
have shipped that nobody would notice for weeks. frame_check.py section 4 pins
all three.

BEHAVIOUR CHANGE, deliberate. The live cross-frame hand-off showed the creator a
section toggle that had NOT been saved: flip it, look, reload, and the section
came back. What the creator shows now is the SOP that is stored. sections_check
5b pins both halves - an unsaved toggle does not travel, a saved one does.

BEHAVIOUR CHANGE, not deliberate, logged as BL-020. A tab switch is a page exit
now, so leaving the wizard with unsaved SOP edits fires T4.3's unsaved-work
guard. Nothing is lost - the guard writes the draft first and T4.3 recovers it -
but it is friction that did not exist, and suppressing a deliberate guard is a
product decision with its own downside. Logged, not quietly handled here.

tests/frame_check.py, 39 checks, new. Two of them exist because of failures
during this task rather than in it:

  - "both documents parse and boot". A const shadowing a function parameter is a
    SyntaxError, and work-package-suite-app.js did not parse at all for one run.
    Four checks in url_state_check went red and not one said "the script did not
    load". Asserting a page's own entry points exist costs nothing.
  - "focus emulation is on, so a focus reading means something". An earlier draft
    called page.call instead of page.ws.call inside a try/except and measured
    nothing, reporting no focus ring anywhere - which looks exactly like a
    finding. Trap 5 in reverse, for the second time in this project.

The four backlog entries logged against this file, re-measured rather than
assumed:

  BL-001  still reproduces (485px in a 390px viewport) but its RECORDED CAUSE IS
          WRONG. --nav-w now computes to 56px, so the injected-style explanation
          is spent. The overflow is the creator's data tables - #asset-body's
          lays out at 520px with no scroll container. frame_check reports the
          offending boxes by selector and skips position:fixed subtrees, because
          the comments drawer parked off-screen at right:844 made the first
          measurement blame the drawer. Pinned, not fixed: T7.2 lays out the form.
  BL-013  CLOSED. It was fixed by S12 in WAVE 4 - wp-creation-styles.css:209
          carries the comment naming this entry - and nobody updated it. It was
          quoted as a live CLAUDE.md violation while planning wave 7 and had not
          been true for four waves. a11y_check walks 120 focusable elements on
          the creator and every one rings at >= 3:1.
  BL-006  15 by the probe's measure, unchanged; different denominator, stated.
  BL-007  68 raw radii by the probe's measure. Nothing has reduced it in four
          waves; it is measured every run now instead of once.
  BL-018  cost a FOURTH probe. frame_check imports set_sop from sections_check
          rather than writing a fifth copy of the workaround. T9.9 owns it.

Probes re-pointed, with reasons in the files: sections_check 5b (drove the live
hand-off), pipeline_check check 2 (read through contentDocument), f_items F4
(drove standalone and embedded; there is one mode now), validation_check
(lost "the wrong tab", gained the SOP gate).

Verified: frame_check 39/39, sections_check 95/95, pipeline_check 44/44,
url_state_check 23/23, validation_check 83/83, a11y_check 22/22,
autosave_check 34/34, aggregates_check 16/16, stepper_check 71/71,
browser_check 71/71, launcher_check 58/58, generalinfo_check 49/49,
rollup_check 63/63, cards_check 44/44, locations_check 58/58.
f_items: F1-F5 fixed, F6 reproduces (T7.2).
Metrics: iframes 1 -> 0, colour literals in rules outside theme-light.css 0,
dialogs 64, <div onclick> 2, .help-tip 18.

Items: B7 D1
Task: T7.1

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-18 14:26:27 -05:00
parent 0dbc240900
commit 12d19446d5
22 changed files with 1250 additions and 433 deletions

View File

@@ -146,3 +146,87 @@ Three things `T7.1` has to settle that no count can answer:
`wp-creation-styles.css`. If that sheet is being scoped or rewritten anyway, they are cheaper
now than they will ever be again — but they are separate items and `T7.1` says to bundle
nothing.
---
## 5. What T7.1 actually did — August 18, 2026
The measurement above assumed one shape of answer: merge the creator's markup and
scripts into `work-package-suite.html`, and pay the 21 selector collisions and 9 global
collisions to do it. That is not what shipped, and the reason is in this document's own
numbers.
**The creator became a top-level page instead of moving into the parent one.** The tab
strip is drawn by both documents, and the two tabs that used to swap a frame are now
links. That satisfies every done-when in the wave file — no iframe, no cross-frame
messaging, `F4` resolved structurally, `CR-006` toggles propagating with no
special-casing, browser back and forward intact — while the wave file's prose ("renders
in the parent document") describes the other route. **Stated as a deviation, not
smuggled:** the boundary is dissolved by making the creator its own document rather than
by dissolving it into another one.
Why, against the counts:
| | Merging into the parent | Making it a page |
|---|--:|--:|
| Selector collisions to resolve | 21 | **0** |
| Script global collisions to resolve | 9 | **0** |
| Cross-frame call sites to remove | 28 | 28 |
| Probe call sites needing rework | ~29 | **2** |
The collisions were never a cost of *dissolving the boundary*. They were a cost of
*merging two documents*, which is a separate change that the boundary happened to be
hiding. §2c called zero markup-id collisions "the single largest piece of good news";
the larger one turned out to be that 29 probe entry points address
`wp-creation-index.html` directly, and a route that keeps that address keeps them all.
What the two duplications mean now:
- **The sequence editor** (9 of the 21 selectors) stays two components, which is what
was confirmed on August 18 — authored in the SOP, adjustable per package. The
duplication is real and stays visible as `BL-015`.
- **Analytics and the feedback panel** (all 9 globals) are still implemented twice. They
are in two documents, so nothing collides, but `T7.10` deletes one copy of analytics
regardless. `showAnalytics` is the one §2b said to check first, and it was right: the
wizard's copy still has no caller.
### The three questions §4 said no count could answer
1. **The creator got the app bar.** It was the only page in `html/` loading neither
`wp-chrome.css` nor `wp-chrome.js`, because `wp-chrome.js` returned early inside an
iframe. Both are loaded now, the header was reshaped into the `.header-left` /
`.header-right` pair the suite page uses so the switcher lands in the same place on
both, and the wizard's layout arithmetic — `chromeHeight()`, `--wp-chrome-h`,
`embed-full` — was deleted rather than adjusted, because there is no frame to size.
2. **Two sequence components**, scoped rather than merged. See above.
3. **`body.embedded` is gone**, and with it `.embed-hide`. The header it hid was
replaced by the app bar; the sample-data controls are visible in a new package
toolbar (`D1`); the analytics button is visible there too until `T7.10` moves it.
The `Dashboard` button in that row became a **tab**, which is the one place the
"fold the toolbar into the tab row" in `B7` actually happened.
### What was checked
`tests/frame_check.py`, 39 checks. Beyond the obvious ones it pins three things this
document could not have predicted:
- **Every old address still resolves.** `?tab=wp`, `?view=dashboard` and `?wp=<id>` are
in bookmarks, in `wp-sidenav`'s link map, and they are the shape the `CR-011` and
`CR-014` emails were specified against (`X1`). The wizard forwards them with
`replace()`, so Back does not bounce. Breaking these silently was the one regression
this task could have shipped that nobody would notice for weeks.
- **Both documents parse.** A `const` shadowing a function parameter is a SyntaxError,
and during this task it stopped `work-package-suite-app.js` parsing at all. Four
checks in another probe went red and not one of them said "the script did not load".
Asserting a page's own entry points exist costs nothing and says exactly that.
- **The behaviour that changed.** The live cross-frame hand-off of a section toggle
showed the creator a toggle that had *not been saved*: flip it, look, reload, and the
section came back. What the creator shows now is the SOP that is stored.
`sections_check.py` 5b pins both halves — an unsaved toggle does not travel, a saved
one does.
`BL-020` is the one thing that got worse: a tab switch is a page exit now, so leaving the
wizard with unsaved SOP edits fires `T4.3`'s unsaved-work guard. Nothing is lost — the
guard writes the draft first and `T4.3` recovers it — but it is friction that did not
exist, and suppressing a deliberate guard is a decision with its own downside, so it is
logged rather than quietly handled inside a structural task.

View File

@@ -42,24 +42,34 @@ means) joins `wp-url.js` and `wp-autosave.js`.
> is cheap once nothing depends on the numbers. `tests/stepper_check.py` names it
> `STEP_COUNT` for the same reason.
### The iframe boundary (matters for `B7` / `T7.1`)
### The iframe boundary - dissolved at `T7.1`, August 18 2026
`work-package-suite.html:383` declares `<iframe id="wp-frame">` with **no `src`**.
`work-package-suite-app.js:581` sets it at runtime to
`wp-creation-index.html?embedded=1&project=<id>`.
`work-package-suite.html` declared `<iframe id="wp-frame">` with no `src`, and
`work-package-suite-app.js` set it at runtime to
`wp-creation-index.html?embedded=1&project=<id>`. The creator was the only page loading
**neither `wp-chrome.css` nor `wp-chrome.js`**, which is why it had no app bar and read
as part of the wizard rather than as a page.
The creator is the only page that loads **neither `wp-chrome.css` nor `wp-chrome.js`** — that is
why it has no app bar of its own and why it looks like part of the wizard. `T7.1` has to give it
that chrome back, or deliberately not.
**There is no iframe in `html/` any more.** The creator is a top-level document with the
same app bar and the same tab strip as the wizard; the `Work Package Creation` and
`Dashboard` tabs are links between the two. `docs/reference/creator-frame.md` section 5
records what was done and why that route was taken over merging the two documents.
Three scripts branch on `window.top !== window.self` and will change behaviour when the frame
goes away:
What a task touching this area needs to know now:
| Script | Line | Framed behaviour |
|---|---|---|
| `auth-guard.js` | 15 | redirects `window.top` to `login.html` |
| `wp-chrome.js` | 17 | returns early, renders no chrome |
| `help.js` | — | suppresses the Help FAB in the child |
| Was | Is |
|---|---|
| `#wp-frame`, `applyEmbedLayout`, `sizeWPFrame`, `--wp-chrome-h`, `.embed-full` | gone; the window sizes the page |
| `?embedded=1`, `body.embedded`, `.embed-hide` | gone; an old link carrying the param is ignored, not half-obeyed |
| four cross-frame calls (`openWpById`, `showDashboard`/`showForm`, `dashApplyFlag`, `applySopSections`) | the URL: `?project=`, `?view=`, `?wp=`, `?flag=`, all read at the creator's own boot |
| `.main-nav` / `.nav-tab` in `work-package-suite-styles.css` | `wp-chrome.css`, because both tool pages draw the strip |
| `inIframe` branches in `auth-guard.js`, `wp-chrome.js`, `wp-sidenav.js`, `help.js`, and `_isTop` in `project-data.js` | gone; `help.js` uses the explicit `WP_HELP_NO_FAB` flag both tool pages set |
**Old addresses still work and must keep working.** `work-package-suite.html?tab=wp`,
`?view=dashboard` and `?wp=<id>` are in bookmarks, in `wp-sidenav.js`'s link map, and
they are the shape `CR-011` and `CR-014` emails were specified against (`X1`). The wizard
forwards them to the creator with `replace()`, so Back does not bounce.
`tests/frame_check.py` section 4 pins all three.
### Pages that are not what the plan implies
@@ -163,9 +173,20 @@ Recorded so wave 9 can prove they went down. Run from `html/` unless stated.
| 6 | `.help-tip` badges | 15 | **15** ✓ | `grep -oE 'class="help-tip"' *.html \| wc -l` |
| 7 | `aria-live` regions | 0 | **0** ✓ | `grep -ohE 'aria-live' *.html *.js \| wc -l` |
| 8 | `pushState` calls | 0 | **0** ✓ | `grep -ohE 'pushState' *.html *.js \| wc -l` |
| 9 | `<iframe>` in `html/` | 1 | **0** ✓ (`T7.1`) | `grep -oiE '<iframe' *.html \| wc -l` |
Dialogs by file: `wp-creation-app.js` 43 · `work-package-suite-app.js` 14 · `users.js` 10 ·
`admin.js` 6 · `index.html` 6.
**At the T7.1 commit** the same commands read: dialogs **64** (the wizard's 14 are gone,
the creator's 43 are `T7.9`'s), `<div onclick>` **2**, `<span onclick>` **2**,
`.help-tip` **18**, colour literals in rules outside `theme-light.css` **0** in all five
page sheets, and **iframes 0** - metric 9 above, added because `B7` is the only item in
the plan whose completion is a count of zero.
Measure colour literals with comments stripped. Four of the five sheets now carry prose
about the hex values they used to contain, and `BL-017` is the entry about a metric that
counted its own explanation.
`<div onclick>` by file: `work-package-suite.html` 10 · `wp-creation-index.html` 1 ·
`work-package-suite-app.js` 1. Both `<span onclick>` are in `wp-creation-app.js`.
@@ -251,6 +272,21 @@ python tests/rollup_check.py # CR-004/CR-018 — codes, and totals that a
python tests/cards_check.py # A7 — card status, footer, localization 44 checks
```
Wave 7 adds one:
```bash
python tests/frame_check.py # B7/T7.1/D1 - is the iframe actually gone? 39 checks
```
**Three probes were re-pointed at `T7.1`.** `sections_check.py` 5b drove the live
cross-frame toggle hand-off, which no longer exists; it now pins the surviving path and
the fact that an UNSAVED toggle correctly does not travel - a behaviour change, recorded
rather than smoothed over. `pipeline_check.py` read the filter through
`#wp-frame.contentDocument`; it reads the page. `f_items.py`'s `F4` drove two modes,
standalone and `?embedded=1`; there is one mode now. `validation_check.py` lost its
"loading the sample on the wrong tab" case for the same reason - there is no wrong tab
on the wizard any more - and gained one for the SOP gate instead.
**Two probes were re-pointed at `T6.5`, and the reason is worth carrying forward.**
`aggregates_check.py` matched the launcher card's exact wording (`"SOP complete"`), and it
also waited for the status line to be non-empty — which stopped meaning "the answer has
@@ -305,7 +341,9 @@ one.
| — | helper-text contrast, worst case | 3.01:1 | **4.56:1** | `T4.6` |
| 3 | `<div onclick>` | 12 | **2** | `T5.1` |
| 1 | native dialogs app-wide | 79 | **64** | `T5.1` (2), `T5.2` (1), `T5.8` (13) |
| 2 | …of those, in the creator | 43 | **43** | unchanged — wave 7/9 |
| 2 | …of those, in the creator | 43 | **43** | unchanged — `T7.9` |
| 9 | `<iframe>` in `html/` | 1 | **0** | `T7.1` |
| 6 | `.help-tip` badges, none keyboard-reachable | 15 | **18** | went UP; `T9.5` |
Metrics 2, 4 and 6 (creator dialogs, `<span onclick>`, `.help-tip` badges) are wave 9's to
move and are unchanged.

View File

@@ -84,6 +84,26 @@ deliberately deferred.
comments drawer is placed correctly relative to its containing block; the containing
block is wrong. `T1.4` reports this as an attributed note rather than a drawer defect,
so nobody is sent to the wrong file.
- **Update, T7.1 - the recorded root cause no longer applies.** Measured after the
rebuild by `tests/frame_check.py` section 6: at a 390px viewport the creator's
`scrollWidth` is still **485** against a `clientWidth` of 390, so the overflow
survives - but `--nav-w` now computes to **56px**, which is the media query
winning. The injected `body{--nav-w:288px}` explanation above is spent; whatever
fixed it, it was not this task.
What is left is a different thing entirely: the widest in-flow boxes are the
creator's **data tables**. `#asset-body`'s table lays out at **520px** with no
scroll container around it, and the other card tables do the same. The probe
reports the offending boxes by selector each run, and deliberately skips
anything inside a `position: fixed` subtree - the comments drawer is parked
off-screen by `translateX(100%)` and its five static children sit out at
`right: 844`, which made the first measurement blame the drawer. That is how
this entry got attributed to the wrong file once already; twice would be a
pattern.
**Not fixed here.** `T7.1` bundles nothing, and the fix is a layout decision -
a scroll container, a stacked card at narrow widths, or fewer columns - which
belongs with `T7.2` laying the form out again. `frame_check.py` **pins** the
current failure, so the check turns red the moment it is fixed and whoever
fixes it is told to close this entry.
- **Update, T1.2:** the 1440px half of this is **resolved as a side effect**, not by intent.
The unbreakable `#wp-usermenu` run that `T1.2` fixed was the cause of four of the five
overflows recorded in wave 0 — launcher, SOP wizard and field view at 390px, and the
@@ -155,6 +175,11 @@ deliberately deferred.
- **Why not now:** retiring them moves text on every creator screen; `T3.2` forbids rendered
change and `T7.1` re-lays-out this page anyway.
- **Suggested wave or follow-up:** `T7.1`. See `docs/reference/tokens.md` §6a.
- **Re-measured at T7.1, unchanged.** `frame_check.py` counts **15** half-pixel
sizes in `wp-creation-styles.css` by `\d+\.5px`, which is the whole sheet
rather than the font-size subset this entry counted, so the two numbers are not
the same measurement and the difference is not a change. `T7.1` re-laid out the
page's chrome, not its type. Carried to `T7.2`, which lays out the form.
### BL-007 — `--radius: 0` is contradicted 45 times in the sheet that declares it
@@ -167,6 +192,12 @@ deliberately deferred.
- **Why not now:** changing 45 radii is the most visible diff available, and `T3.2` must
produce none.
- **Suggested wave or follow-up:** `T7.1`. See `docs/reference/tokens.md` §6c.
- **Re-measured at T7.1: 68, not 45.** `frame_check.py` counts raw
`border-radius:` declarations that do not resolve through a `var()`. The rise is
the counting method rather than 23 new radii - this entry counted values, the
probe counts declarations - but the direction is the point: nothing has reduced
it in four waves, and it is measured every run now instead of once. Carried to
`T7.2`.
### BL-008 — There is a second brand blue: `#2563d6`
@@ -253,6 +284,21 @@ deliberately deferred.
- **Suggested wave or follow-up:** `T7.2`, or `T9.5` with the `C1` audit if it survives the
rebuild. The fix is the ring `T3.4` established: `outline: 2px solid var(--cds-focus);
outline-offset: -2px`, which `console.css`, `wp-chrome.css` and now the wizard all use.
- **CLOSED at T7.1 - it was already fixed, and this entry was stale.**
`wp-creation-styles.css:209` carries an `S12` comment naming this entry, and
`:219` sets exactly the ring prescribed above. So it was closed in **wave 4**,
by `S12`, and nobody came back to say so - the same way `BL-014`'s launcher half
turned out to be closed by `T4.7`.
Measured rather than read, twice: `frame_check.py` reports a focused creator
input as `outline solid 2px`, and `a11y_check.py` walks **120 focusable elements
on the creator** and finds every one of them ringing at 3:1 or better.
Worth saying plainly, because this entry was quoted as a live `CLAUDE.md`
violation while planning wave 7 and it had not been true for four waves: a
backlog entry is a claim with a date on it. Re-measure before acting on one.
The first thing `frame_check.py` does with focus is assert
`document.hasFocus()`, because an earlier draft called `page.call` instead of
`page.ws.call` inside a `try/except` and silently measured nothing at all -
which reported "no ring" for every control and looked exactly like a finding.
### BL-015 — The creator's stepper tabs are still forced uppercase
@@ -323,6 +369,13 @@ deliberately deferred.
- **Suggested wave or follow-up:** `T7.1`, or wave 9 with `C2` if the gate survives the
rebuild unchanged. Either way `browser_check.py`'s fixture should adopt the `{sop, state}`
shape so it stops being the only place this discrepancy is visible.
- **Update, T7.1 - the gate survived, and this has now cost a fourth probe.**
The WP tab is no longer a frame swap, but it is still gated on `sopComplete`,
which is still `restoreSavedSOP()`'s answer. `frame_check.py` had every
creator route land on the gate panel until it seeded a readable SOP; it now
**imports `set_sop` from `sections_check.py`** rather than writing a fifth
copy, so the workaround is in one place and disappears when the fixture is
fixed. Four probes is enough evidence: `T9.9` owns it.
### BL-019 — A cost code that has left the list is silently blanked on edit
@@ -364,3 +417,30 @@ deliberately deferred.
`T4.7` added, which post-dates this entry. So the launcher half of BL-014 is closed;
what is left is `field.html`'s `.fld-search`, and `T9.5` should re-measure that one the
same way rather than inheriting this entry's wording.
### BL-020 — Switching from the SOP wizard to the creator can now prompt to leave
- **Found during:** T7.1
- **Where:** `html/wp-autosave.js:96` (the `beforeunload` guard), reached from the
tool tabs in `html/work-package-suite.html`
- **What:** the Work Package Creation and Dashboard tabs used to swap an iframe
inside one document. Since `B7`/`T7.1` they are links to another document, so
leaving the wizard with unsaved SOP edits fires `T4.3`'s unsaved-work guard and
the browser asks whether to leave. The guard is behaving exactly as designed;
what changed is that a routine tab switch is now a page exit.
Nothing is lost either way - the guard writes the draft before prompting, and
`T4.3`'s recovery restores it on return - so this is friction, not data loss.
Note that `sopIsDirty()` compares against the fingerprint taken at load and at
`completeSOP()`, so **typing anything at all** makes the wizard dirty until the
SOP is completed. On a twelve-step form that is most of the time somebody spends
on it.
- **Why not now:** suppressing a deliberate guard for one navigation is a product
decision with a real downside - it is the same mechanism that stops a closed tab
losing work - and `T7.1` is forbidden to bundle anything. Found by
`frame_check.py`, which filters the console line rather than hiding it, and says
why in the comment.
- **Suggested wave or follow-up:** wave 9, with `C2`. If it is to be suppressed,
the honest version is an in-app navigation that flushes the draft and marks the
departure intentional, not a blanket disabling of the guard. If it is to be
kept, `T7.2`'s side navigation is the place to make saving obvious enough that
the prompt stops being a surprise.