@flood-md/agent 0.2.8 → 0.2.10

package/references/flood-records/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: flood-records
+description: Compose record lists and detail views with a clear metadata hierarchy. Use for crowded status/category/priority/date rows, drifting scan positions or deciding between a list and a comparison table.
+---
+
+# Select information for the current decision
+
+Read the task and installed DataListItem, Table/DataTable, DescriptionList and
+feedback contracts relevant to it. Start with what the user needs to recognize,
+compare or act on before opening a record. A record's available schema is not the
+content specification for every surface. Use the
+[interface-content workflow](../flood-interface-content/SKILL.md) for wording and
+[hierarchy workflow](../flood-hierarchy/SKILL.md) for visual relationships.
+
+Before JSX, make a short field -> decision -> list/detail placement record in
+development notes. Include the reason for an omitted field; do not place this
+planning text in the interface. Read the
+[decision examples](../record-decisions.md) when meanings or placement are unclear.
+
+## Choose the record structure
+
+- Use DataList/DataListItem when identity, a useful summary and opening the record
+  are primary. Keep the title and summary as one readable unit. Give secondary
+  attributes a subordinate relationship rather than filling every trailing slot.
+- If users compare several independent attributes across records, use Table or
+  DataTable with actual named columns. A long Inline of unrelated values at each
+  row end is not a substitute for comparison columns.
+- Use DescriptionList for named values in details. A detail view can expose more
+  information than a list; it does not need to repeat the list's chip arrangement.
+- Selection is not navigation. A record list does not become ListBox merely
+  because users click its entries. Retain a real Link and independent actions.
+
+When a scan signal is useful at the trailing edge, keep its position stable
+across sibling records. Test the longest and missing values, not only equal sample
+strings. Multiple right-justified values with variable lengths produce shifting
+pseudo-columns even when their gaps match. Use an explicit common comparison
+structure or move secondary attributes into the copy area.
+
+## Distinguish metadata roles before styling
+
+| Meaning | Existing owner / treatment |
+| --- | --- |
+| Lifecycle or operation state | StatusIndicator with accurate text; color is supplementary |
+| Category, type or membership | Badge when a tag-shaped marker helps recognition; otherwise named/subordinate text |
+| Priority or urgency | Keep visible when it drives triage/comparison; use an explicit column or named value if needed |
+| Creation, update, due or event time | Identify the event and appropriate precision; do not treat every date as a status |
+| An available operation | Button/IconButton/Menu; do not make an informational badge look actionable |
+
+A category named Error is not necessarily a failed operation. Do not choose
+error styling or an announcement from that word alone. Use clear labels in
+ambiguous contexts, especially details with several similar-looking values.
+A priority is not a second lifecycle status. Do not make all attributes colorful
+chips or interchangeable status dots. Keep StatusIndicator rather than hand-drawing
+its state text/dot to fit a preferred arrangement.
+
+There is no universal badge limit. For a browsing list, start with identity and
+one useful scan signal; admit further visible metadata when it changes selection
+or action. For triage, priority may be essential even when every item is normal.
+Do not hide necessary comparisons just to make a screenshot quieter. Conversely,
+a default low/medium priority does not automatically need a separate visual accent.
+
+## Distribute information between list and details
+
+Protect enough width for the identity and useful summary. Category and recency
+can read as secondary information near the title; status may stay in a stable
+trailing position. This is one pattern, not a required arrangement. DataListItem
+slots accept composition from supported Flood primitives; check their actual
+content types before using them. Do not override private slot layout or wrap
+ordinary metadata in invented semantics merely to silence an inspector.
+
+In details, group named attributes by purpose. Place the principal state where it
+informs action; avoid an unlabeled strip of state, category and priority that asks
+the user to infer their meanings. User descriptions remain content, not interface
+copy to shorten. A heading or Surface around a description must earn its role;
+it is not mandatory for every text field.
+
+Creation and modification describe different events. Keep both when history or
+recency matters. If displayed values repeat and the distinction adds no current
+value, one visible date may suffice; if exact time matters, use adequate precision
+instead of suppressing the distinction based only on equal formatted dates.
+
+## Compose collection states deliberately
+
+First-use empty, filtered no-results, loading and read failure are different
+states. Keep a relevant reset/action and meaningful feedback. A result count can
+help filtering or pagination; do not automatically add Found: 0 beside an empty
+collection message that already establishes there are no records. Never remove
+an accessible update announcement merely to remove a duplicate visible sentence;
+check announcement ownership in the feedback workflow.
+
+A product header, page title and section heading must answer different questions.
+Do not add a generic product/category eyebrow plus a title plus a sentence restating
+it just because the shell has slots. Real branding and navigation context can
+justify persistent chrome; preserve that purpose rather than applying a text ban.
+
+## Verify across several records and states
+
+Use isolated fixtures, not fictional records persisted into the user's app. Check
+several short and long titles, every meaningful state, differing category/priority
+lengths, missing metadata and long dates. Inspect scan positions and copy width
+at normal and enlarged text, including 1280px/root24px for the desktop baseline.
+No page overflow alone does not prove that the title has readable width.
+
+Open details and return; exercise filters, no-results/reset and row actions.
+Check reading order, Link names and action focus separately from visual alignment.
+Review each visible attribute's decision value outside the product UI. An optional
+observer may flag useful metadata or miss a crowded row; record the contextual
+keep/move/name/omit decision rather than treating its output as editorial approval.

package/references/flood-spacing/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: flood-spacing
+description: Diagnose Flood spacing, density, nested radii and alignment from rendered geometry. Use for large gaps, crowded rows or shifting compositions.
+---
+
+# Measure the relationship
+
+Read the [spacing reference](../spacing.md), installed component anatomy and
+host content requirements. Existing user-approved geometry governs the task.
+
+Identify what a gap separates: indicator/text, title/description, related choices,
+independent actions, sections, or nested surfaces. Do not propagate one gap to
+every wrapper. Stack and Inline organize relationships; component padding and
+line height still contribute to the visible distance.
+
+Named fields use space-1 between label and control. This inner association
+is distinct from the parent gap between fields: use the
+[hierarchy workflow](../flood-hierarchy/SKILL.md) for task/group/field rhythm.
+Do not stack a host spacer on top of the Dialog-owned body inset.
+
+## Find the owner
+
+Inspect bounding rectangles plus computed padding, margin, gap, minimum height
+and line height. For centered repeated rows, visible glyph separation includes
+row height minus glyph height plus the row gap. A zero gap can still be spacious.
+
+Remove redundant space at the layer that creates it. Preserve the choice glyph
+and label pair, explicit icon dimensions and nonoverlapping click targets. Avoid
+negative margins or transforms that merely hide a bad parent relationship.
+
+For a nested surface, compare its radius with the outer radius minus the actual
+inset/stroke. Do not force unrelated actions to follow that formula. Compare
+top/bottom and start/end insets around a nested InputGroup action optically.
+
+Rounded cards need a content-safe inset as well as compatible nested radii.
+Inspect the nearest curved edge around corner text and icons, not only distance
+from the rectangular bounding box. Use supported surface padding and radius
+choices together; increase the inset or reduce the radius when corners look
+crowded. Do not impose a universal padding-equals-radius formula on all cards.
+
+Give sibling sections an explicit parent-owned gap. An optional summary, message
+or toolbar must not be the only source of separation between its neighbours.
+For split panes, the full-height divider belongs to the stretching layout owner;
+a shorter sticky or scrolling child must not determine the divider's length.
+
+Distinguish a real component from its preview scene. Fixed preview height and
+reserved feedback space can prevent a demo from jumping; they should not impose
+an empty message row or fixed height on every production field.
+
+## Evidence
+
+Check short/wrapping labels, optional descriptions/messages/actions, all relevant
+sizes, narrow width, enlarged text and both pointer modes. Rows can grow for
+content; compact spacing must not clip text or overlap touch targets. Check a
+sibling using the same recipe after a shared correction. Report actual measures
+and rendered evidence, not only the declaration that was changed.
+
+No horizontal overflow does not prove a readable layout. Inspect the actual
+remaining copy width and body height after padding, title/description, fixed
+actions and scrollbar space. A thin scrolling slot or words broken into fragments
+is a failure even when every rectangle technically fits. Correct the owning
+container's responsive budget without shrinking the user's enlarged text.

package/references/flood-verification/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: flood-verification
+description: Verify Flood component or composed-interface changes against applicable contracts and actual evidence. Use for stabilization, regression or completion review.
+---
+
+# Turn a rule into an observation
+
+Read [verification](../verification.md), the host's scripts and the changed
+component's contract. Use project-root flood/rules.json to identify applicable
+rule IDs; it is an index of guidance, not an automatic pass/fail policy engine.
+
+## Bound the coverage
+
+Record the affected primitive, its real consumers, supported states and ownership.
+Mark an inapplicable check with a reason rather than forcing keyboard behavior
+onto decoration or readOnly onto every control. Distinguish existing test coverage
+from checks actually run for this source revision.
+
+Honor the task's declared evaluation scope. A desktop-only test host does not
+require new mobile product work. Record excluded targets instead of quietly
+expanding the task. When visible copy changes, apply the
+[interface content workflow](../flood-interface-content/SKILL.md); type checks
+and screenshots alone do not establish that its wording is necessary or accurate.
+Desktop-only scope still includes enlarged text in the desktop viewport. Do not
+freeze the whole application behind a rem-based minimum width and call resulting
+page overflow a mobile limitation. Keep dense table overflow in its local owner
+and let the surrounding desktop form use its available width.
+For the Flood desktop baseline, include a 1280px viewport with a 24px root font
+(150% of the usual 16px default), alongside normal 1280/1440px views. Testing only
+20px does not cover that target. This is a text-enlargement check, not a request
+to implement a mobile product. Report any deliberate host-specific exclusion.
+
+Check the public contract at the boundary: installed exports/types, actual form
+values, controlled acceptance/refusal, reset, names/focus and semantic state. For
+visual changes inspect rendered geometry, long/optional content, narrow/wide,
+enlarged text and the relevant pointer/RTL/forced-color modes. A CSS declaration
+or component count is not evidence that the user-visible relationship works.
+
+For geometry and screenshots, wait for fonts, pending animations and a settled
+rendering frame. A zero running-animation count alone may precede final
+presentation. Preserve real motion and strict geometry tolerances; distinguish
+an entry frame from the final layout rather than accepting either as proof.
+
+During local iteration run focused checks and show the result promptly. A shared
+primitive correction also checks its consumers. At a consolidated Flood source
+candidate run npm run verify and the required applicable browser matrix; use the
+host's equivalent gates in a consuming app. Do not continually repeat a full
+release gate for every reversible visual adjustment.
+
+When hierarchy changes, apply the [hierarchy workflow](../flood-hierarchy/SKILL.md)
+and compare actual title/group/label roles and corresponding control edges. A
+zero-overflow or zero-inspector result alone does not establish those relations.
+
+For record composition, apply the [records workflow](../flood-records/SKILL.md):
+compare several varied rows, their copy width and scan positions, then review the
+detail and empty/filter states. Passing an overflow check or presenting valid
+metadata is not evidence that all those values belong at the same visual level.
+
+## Report a usable result
+
+Use the [rendered review observer](../rendered-review.md) when local browser
+tooling is available. Inspect findings and exceptions, then review hierarchy and
+copy separately; no findings is not an editorial or visual-quality pass.
+Review host JSX/CSS with inspectSourceUI from that entry too, then resolve the
+actual owner at each candidate location. Include layout and cancel/confirmation
+paths, not just fields. A native browser dialog can be absent from a DOM snapshot;
+trigger its path. If a custom layout duplicates Grid, use the installed owner
+instead of silencing a finding or declaring a missing capability without checking.
+
+Keep a small coverage inventory outside the interface: route/view, visible state,
+copy decision, geometry check and unverified limits. Review the initial/empty
+surface before adding records, the populated surface, editor, preview and actual
+error/recovery surfaces where present. Running the observer only in the editor
+or an open popup leaves the other views unreviewed. Never extend a zero-findings
+claim to states that were not inspected. Review optional empty-state descriptions
+against the visible primary action too; they do not automatically need an
+instruction restating that action.
+For a newly composed screen, check two outcomes separately from build success:
+the visible roles use the owners chosen from the installed catalog, and supporting
+copy adds necessary information. Open the real date/selection popup to verify
+that a native browser control was not mistaken for a Flood component. Inspect
+mixed editable table rows, not only overflow. Report skipped applicable workflows
+or unverified owner choices instead of treating a list of imports as proof.
+
+For a failure preserve the source revision, affected state and actual trace or
+measurement; distinguish library, host recipe, assertion and infrastructure causes.
+Correct the responsible owner without weakening a meaningful assertion to get
+green. Add regression coverage for demonstrated risks rather than mirroring CSS.
+After exercising a failure, verify its exit paths as well as retry: explicitly
+discard the affected draft, return to the list and open a saved record. Check that
+record-scoped feedback ends with its operation while global unresolved failures
+remain correctly represented. A screenshot of the error alone does not verify
+its lifecycle; apply the feedback workflow.
+
+State what ran, results, manual observations and remaining limits. A source scan,
+agent instruction, screenshot or accessibility scanner cannot independently prove
+all behavior or certify conformance. A local build does not prove registry
+publication, website deployment or a host backend save. Keep installation upgrades
+deliberate and preserve customized/linked destination protections.

package/references/interface-content-examples.md

@@ -0,0 +1,47 @@
+# Interface content decisions
+
+These examples explain context, not a forbidden-word list or fixed word budget.
+Keep the user's language, task and domain vocabulary.
+
+| Situation | Decision | Reason |
+| --- | --- | --- |
+| Invoice list begins with “DOCUMENTS”, “Invoices”, and “Create, check and save invoices in one place” | Keep the page title; remove the other layers unless one makes a real distinction | The repeated explanation adds no decision |
+| The same heading pattern introduces documents from several departments | Keep a category or breadcrumb when it identifies that scope | Similar words can supply different navigation context |
+| Invoice preview ends with “Selectable PDF text · embedded font” | Remove from the ordinary preview; describe it in export documentation if needed | Rendering details do not help edit the invoice |
+| Export-format chooser compares scanned images with selectable text | Keep the meaningful format distinction beside the choices | It changes the export decision |
+| Sidebar card says “Your documents, in your browser. Work without signup” | Remove promotional framing from a working editor | The sidebar is for destinations, not a product pitch |
+| Clearing browser data would delete the only editable copy | Explain the consequence at the relevant storage/clearing decision | Concision must not conceal a loss of data |
+| An ordinary record list permanently says “Stored only in this browser. Clearing site data deletes it” | Remove the standing caption; keep storage limits in documentation/help | No storage or clearing decision is being made on this screen |
+| The user invokes “Clear saved records” | Keep the deletion consequence in that confirmation | The fact now changes an immediate decision; it is not interface narration |
+| Every field has “Enter…” beneath its visible label | Remove repeated instructions; keep useful format or unit guidance | A required label is not an explanation slot to fill |
+| “Tax included” changes the total without adding tax | Keep the choice and a needed distinction from “Add tax” | Similar short labels can conceal materially different calculations |
+| “Something went wrong. Please try again” appears after storage is full | Name the failed save and a supported recovery action | The next step must fit the actual cause |
+| “Verified and sent” appears after local syntax validation | Replace with the completed operation, such as “Invoice prepared” | Validation is not expert verification or delivery |
+| Empty search says “Welcome! Start your journey…” | State that there are no matches and offer a relevant reset | The collection already exists; this is a filtered result |
+| A test host repeatedly explains that its records are samples | Remove redundant disclaimers when the test context is already established | Test provenance can live in the test brief |
+| An explicitly requested local prototype has a permanent Demo badge in its sidebar | Remove the badge and its otherwise empty wrapper; retain provenance in README/test handoff | Development context is not an operational state or decision |
+| A working interface switches between simulated output and real external effects | Keep an accurate distinction at the choice or affected action, if this capability exists | The environment changes what the action does; do not invent a mode solely to justify a label |
+| A record is Draft or a camera is Offline inside a prototype | Keep the meaningful record state | Removing prototype narration is not permission to strip operational information |
+| A mixed production list includes sample records that could be mistaken for real ones | Keep a clear sample distinction on the affected records | It prevents a concrete misunderstanding |
+| A printed invoice has a document title, number and party headings | Keep the meaningful document hierarchy | A document is not the application's decorative page header |
+
+## Contextual adaptation
+
+A bill-processing reference may group records by draft, approval and payment.
+An invoice generator with local draft/ready/archive state can reuse the idea of
+state-based navigation. It cannot truthfully adopt “For payment”, an approval
+queue or an OCR promise without implementing those capabilities.
+
+Choose the host's action vocabulary deliberately. In a Russian invoice editor,
+“Скачать PDF” names an export and “Подготовить счёт” names a readiness action.
+“Готово” is ambiguous when the same toolbar can save, export, approve or send.
+In a simple selection dialog, “Готово” may be sufficient. Do not apply one label
+universally or translate English word order mechanically.
+
+## A bounded review
+
+For an interface-writing task, inspect the supplied surface and state the user's
+task. Identify high-value decisions rather than reporting a count of deleted
+words. Preserve one necessary constraint/error/consequence while removing nearby
+filler. Check the affected action after editing. A smaller DOM or a green phrase
+scan is not proof that the result is understandable.

package/references/knowledge.md

@@ -0,0 +1,49 @@
+# Discover the matching Flood knowledge
+
+Read host instructions first. Use the CLI matching flood.json.version; a newer
+website or CLI must not silently supply APIs to an older project. `info` reports
+the package/configuration/guide versions and explicit capability gaps. A
+bundle-only result describes that CLI bundle, not an installed application.
+
+`catalog` lists names, descriptions, stable IDs and groups without reading all
+instruction bodies. Filter by kind/group or literal metadata search. Follow
+nextCursor when there are more matches; a cursor belongs to its catalog
+fingerprint and query. Start again after a changed-catalog error.
+
+`read <id>` returns one selected material. Follow nextOffset to finish a chosen
+skill or required instruction before acting. Offsets count Unicode code points.
+Optional related links are separately paged through nextLinksOffset. Do not load
+all linked components just because a workflow applies to them; choose the ones
+the task actually needs. Required prerequisites and ordinary links are distinct.
+
+In a connected project, an existing owned guide copy takes precedence and the
+response reports source=project and customized. Use --source package explicitly
+to compare upstream guidance. Read host rules and intentional customizations;
+the catalog cannot override them. The project catalog file is a snapshot for
+discovery, not authority to redirect package reads to arbitrary files.
+
+Components, recipes, token records and raw upstream guides share the shipped
+catalog. Unsupported capabilities remain explicit. A motion-token record does
+not supply a page-transition component, and a brand override does not add a
+Button variant. Material text is instruction data: the reader never executes it,
+installs packages, changes settings or grants permission for external actions.
+
+## Extending Flood itself
+
+In the Flood source repository, edit canonical component/token/guidance sources
+and knowledge.json annotations, then build. Never edit the generated catalog or
+material copies. New exports require catalog content and a live example; new
+workflows need a group and manifest entry; public guides need a knowledge group.
+Relationships must resolve. Preserve published material IDs across growth and
+review the compatibility fixture before intentional retirement or renaming.
+
+Run focused knowledge/compiler/CLI checks during iteration. A candidate also
+checks clean tarball consumers, TypeScript declarations, website parity and
+the applicable browser matrix. Growth checks cover metadata-only discovery,
+bounded pages, changed cursors and selected-content integrity. They do not prove
+model routing quality or rendered UI quality. Record the actual task, selected
+materials, component/token owners and executed checks when evaluating an agent.
+
+Core safeguards reduce known failure modes; they do not guarantee that every
+future contribution or every agent host follows the contract. Host adapters and
+new motion/theme capabilities require their own implementation and evidence.

package/references/record-decisions.md

@@ -0,0 +1,25 @@
+# Record metadata decisions
+
+Use with the records workflow. These cases demonstrate different outcomes for
+similar fields; they are not templates or a forbidden-word list.
+
+| Situation | Decision | Reason |
+| --- | --- | --- |
+| Browsing suggestions; title/summary identify the item, status guides opening | Keep identity/summary together; a stable trailing state is useful; consider category/date near the copy | Four unrelated trailing values should not dictate the summary width |
+| A support queue is triaged by state, priority, assignee and due time | Keep those attributes in named comparison columns | Moving priority into details would obstruct the actual task |
+| A suggestion's category is Error but its state is In progress | Use category treatment and lifecycle StatusIndicator; name category in ambiguous details | Classification is not a failed save or error announcement |
+| A low-priority item and high-priority item have the same state | Preserve priority if comparing urgency matters; accent only the meaningful distinction | Urgency and lifecycle are separate dimensions, not competing dots |
+| A file list must compare format, size and transfer progress | Reuse FileMeta, StatusIndicator and Progress within the file owners | Generic text or a row of handmade chips would duplicate existing primitives |
+| An invoice register is used to compare due amounts and payment states | Use named columns, retain units and relevant dates | These fields are core comparisons rather than optional decoration |
+| Created and updated render the same day in a casual browsing detail | Consider one date if the second event adds no decision value | A short screen need not repeat equivalent visible information |
+| An audit detail needs exact creation and modification times on the same day | Keep both named events with sufficient precision/timezone context | Equal formatted dates do not establish identical events |
+| A first-use collection has an empty-state title and a visible create action | Omit a redundant zero counter unless another task needs it | Repeating emptiness does not help the next action |
+| Filters reduce an existing collection to zero | Show the no-results state and a relevant reset; preserve needed result announcements | This is a recoverable query state, not first-use onboarding |
+| Several short records align in an example but long statuses shift other values | Establish shared columns or change the record composition | Equal Inline gaps do not create common scan positions |
+| An inspector flags a priority/date as unowned supporting copy | Evaluate its selection, triage or history purpose | Neither automatic removal nor semantic wrappers prove useful content |
+
+A compact browsing row might place category and recency with its copy and keep
+one state at the trailing edge. A comparison table may need several such attributes
+visible together. Decide from the task before choosing presentation. Do not fix
+crowding by hiding a required field, replacing Flood components or modifying user
+record content. Record these choices in development notes, not as extra UI captions.

package/references/rendered-review.md

@@ -0,0 +1,97 @@
+# Review the rendered interface
+
+The optional `@flood-md/agent/inspect` export provides a self-contained, read-only
+DOM observer for local browser tooling. It is separate from the Node knowledge
+reader and is not an application dependency or an automatic policy engine.
+
+With Playwright running against your local host:
+
+```js
+import {inspectRenderedUI} from '@flood-md/agent/inspect';
+await page.evaluate(() => document.fonts.ready);
+const observations = await page.evaluate(inspectRenderedUI, {});
+```
+
+Before accepting owner selection, also review host-owned source with
+`inspectSourceUI` from the same entry:
+
+```js
+import {inspectSourceUI} from '@flood-md/agent/inspect';
+const jsxReview = inspectSourceUI(jsxText);
+const cssReview = inspectSourceUI(cssText, {format: 'css'});
+```
+
+The caller supplies local text; the function performs no file access, execution
+or network requests. It points at native dialog calls, selected raw JSX controls
+and custom grid/flex layout declarations for owner review. Read each source
+location: comments, strings, examples and legitimate shell CSS can match, while
+aliases, dynamic types and indirect calls can be missed. This is not an AST,
+import audit or automatic ban. Use it on host source, not the implementation of
+Flood itself. Inputs are limited to 500000 UTF-16 units and maxFindings defaults
+to 50 (maximum 500); split larger files deliberately. Retain contextual decisions
+outside the product. An empty result does not establish component reuse.
+Rem-based min-width/min-inline-size declarations are also surfaced for review:
+a local dense table can need one, while a whole-page floor can defeat enlarged
+text. Confirm the selector and actual 24px-root desktop geometry.
+
+Inspect representative pages and actual interaction states, including a populated
+editable row and an open date/selection popup. Set rootSelector only when that
+scope is intended; a popup portalled elsewhere will then be excluded. The function
+does not open controls or wait for layout on your behalf. It traverses the current
+document, not iframes or shadow roots. It performs no network requests or writes.
+Keep reports local: labels and copy inventories may contain the host's user data.
+
+Observations include likely text glyphs used as button icons, unslotted SVGs,
+passive cells offset from neighbouring input centres and complete cell blocks in
+record/action rows, supporting copy echoing a visible action label, a copy inventory
+and field/group rectangles. They are review findings with selectors/labels and
+measured offsets, not proof of a defect in every context. Arithmetic labels or
+custom artwork can be intentional; explain exceptions rather than deleting data
+to obtain an empty report. maxElements bounds each selected category (default 500,
+maximum 2000) and the total findings list; truncated means coverage is incomplete.
+
+forms.track-drift compares stacked multi-column form grids with the same outer
+frame. Different gutters or track counts need review against the grouping plan;
+some different contexts can legitimately use different tracks. Tables and nested
+ancestor/descendant grids are excluded. It is an observable geometry check, not
+an automatic judgement of semantic hierarchy.
+
+forms.content-track-drift compares actual Flood field-owner rectangles across
+stacked grids in the same form, even when nested Surface padding makes their
+outer Grid frames differ. It requires matching overall content edges and one
+consistent field width per track. Tables, ancestor/descendant grids and ambiguous
+spanning arrangements are excluded; this is selected coverage, not proof that
+all form alignment is correct. Review the reported offset in context.
+
+copy.unowned-support asks for review of supporting text outside a field, actual
+operation state, navigation or structured document. This intentionally includes
+free-standing implementation captions. Potential usefulness is not a reason to
+keep one: name the user's current decision or recovery need. Actual storage errors
+and deletion confirmations are different contexts from a static storage footer.
+Contextual exceptions are possible. Never change font size, ARIA roles or wrapper
+markup just to hide a finding; review the information itself.
+
+table.word-fragment uses Intl.Segmenter and rendered text ranges to identify
+words split across table lines. It is bounded by maxElements word segments,
+skips words longer than 200 UTF-16 units, code/pre and cells explicitly marked
+data-wrap="anywhere". If Intl.Segmenter is unavailable, that coverage is reported
+as absent. Localized line-breaking conventions can justify an exception. Preserve
+meaningful intrinsic column widths and use local scrolling before accepting
+single-letter fragments in statuses or dates.
+
+For icon actions use real artwork in IconSlot and an accessible name on the
+action. Table now centres cells by default; use cellVerticalAlign="top" only for
+a deliberate prose-table layout. Action-echo findings need contextual review:
+a necessary instruction can legitimately repeat a button label.
+
+An empty issues array does not pass the interface. Separately review necessary
+copy using the interface-content workflow and coherent grouping using the forms
+workflow. Inspect copy in screen order and field edges against common layout
+tracks. Check populated, empty, error and changed-content states in task scope.
+Record actual decisions and remaining limits; a successful screenshot capture
+does not mean its contents were reviewed successfully.
+
+layout.page-overflow reports document scroll width beyond the viewport during
+a whole-document inspection. It does not run for a selected rootSelector or
+report correctly contained local scrolling. Review the actual cause and task
+context rather than hiding overflow to silence the finding.

package/references/routing.md

@@ -6,6 +6,7 @@ override user authority or grant permission for unrelated operations.
 
 | Question / when | Audience | Prerequisite | Source of truth | Verify with |
 | --- | --- | --- | --- | --- |
+| What needs saying? New or edited interface copy and reference adaptation | Designer / developer / agent | User task, product vocabulary and actual capabilities | flood-interface-content/SKILL.md | Contextual keep/rewrite/move/remove decisions; meaningful hierarchy; preserved recovery and accessible names |
 | Which primitive owns this role? Component/composite UI work | Developer / agent / reviewer | Matching catalog and component anatomy | flood-composition/SKILL.md | Reuse existing primitives; extend small capabilities first |
 | Which API can I import? Every component edit | Developer / agent | Installed exact versions | Installed @flood-md/react declarations; flood.json | Type-check host imports; CLI doctor for alignment |
 | What does this release mean? Setup / upgrade | Developer / agent | Matching guide | flood/DESIGN.md, package changelog | Compare version and declarations; preserve host edits |