fimo 0.17.0 → 0.19.0

package/assets/skills/fimo-migration/references/content.md

@@ -2,24 +2,72 @@
 
 Model CMS content before page implementation.
 
+## Editorial Modeling
+
+Model editorial content the way an editor should see it in Fimo, and keep the
+source's behavior and content shape. A better model never silently redesigns the
+site: the same routes render the same content, in the same order, with the same
+copy. Record the source-to-Fimo mapping - source file, frontmatter key, or
+export column -> content type, field, block, or reference - in the canonical
+manifest and the content plan.
+
+- **Blocks first.** Repeatable or structured editorial sections (hero, feature
+  grid, FAQ, testimonial list, pricing tiers, a page's section stack) become a
+  `blocks` field with named variants; rich bodies become `richtext`. Blocks and
+  references are content-editable, so model the structure instead of flattening
+  a section stack into loose strings or one opaque value.
+- **JSON is the last resort.** Use `json` only for opaque or
+  application-owned data that no Fimo-native model fits, and record the concise
+  reason in the content plan and the report. A `json` blob holding editorial
+  copy is unmodeled content, not a migrated model.
+- **Global chrome is content.** Header, footer, navigation, and site settings an
+  owner edits become singleton content types (navigation items as blocks or
+  references, not one label per link). Labels stay for genuinely small UI copy
+  and reusable translations.
+- **Names are editor-facing.** `heroHeading`, not `H1`; `features`, not
+  `field_04`; `Navigation`, not `NavigationEs`. Never name a content type,
+  field, or block variant after a markup tag, an HTML attribute, a locale code,
+  or a source column index, and group related fields in the order an editor
+  reads them.
+
+## Markdown/MDX is source evidence, not a runtime source
+
+Markdown/MDX files in the source tree or under `.fimo/migration/` are evidence
+for the migration, never the migrated app's runtime content source. Claiming
+content was migrated requires that the content was pushed to Fimo and the
+consuming pages read it back through the Fimo content APIs. A page still
+reading `.md`/`.mdx` files at build or request time is unmigrated content, not
+a covered item.
+
+- Long prose bodies belong in `richtext` fields and must render through the
+  Fimo rich-text primitives, not a Markdown pipeline.
+- Custom MDX/React components embedded in prose are application code: preserve
+  them as components rendered by the consuming page, or record them as
+  unresolved. Never silently drop them during HTML-to-richtext conversion.
+- Split editable prose around executable React/MDX children. Keep the children
+  in their original render order and wire the surrounding text to Fimo; do not
+  flatten or replace executable nodes with one additive “Page content” block.
+
 ## Detecting Dynamic Collections (no CMS export)
 
 When there is no first-party CMS export (most url-only and website-builder
 migrations), dynamic content still exists and must be modeled. It shows up two
 ways:
 
-1. **Repeated route groups** - many sibling routes share a path prefix
-   (`/blog/*`, `/vr-games/*`, `/locations/*`). Each group is a collection.
-   Ignore locale prefixes (`/en-be/`, `/fr/`): a locale segment is never a
-   collection name.
-2. **Repeated in-page blocks** - a single page renders an array of
-   structurally-identical items: card grids, list rows, tiles, carousels, logo
-   walls. Games, locations, team members, testimonials, pricing tiers, FAQs,
-   news teasers, and feature lists are almost always collections even when the
-   source renders them inside one page.
-
-After the source-faithful rebuild, treat **any hardcoded array of 3+ items with
-the same shape** as a collection candidate. Do not leave it hardcoded.
+1. **Repeated route groups** - many sibling routes may share a path prefix
+   (`/blog/*`, `/vr-games/*`, `/locations/*`). Treat the group as a collection
+   candidate and inspect the route modules, identity, and editability before
+   deciding. Ignore locale prefixes (`/en-be/`, `/fr/`): a locale segment is
+   never a collection name.
+2. **Repeated in-page sections** - a single page may render an array of
+   structurally-identical items: card grids, list rows, tiles, carousels, or
+   logo walls. Read the consuming code and source intent before deciding whether
+   the values are a collection, a `blocks` field on a single, labels, or
+   application-owned data.
+
+Repetition is evidence, not an automatic threshold. Do not convert every array
+or object into content, and do not leave a collection-shaped source structure
+hardcoded after the worker has established that editors should manage it.
 
 For each candidate:
 
@@ -27,35 +75,67 @@ For each candidate:
   `location`/Locations, `newsPost`/News, `testimonial`/Testimonials,
   `pricingPlan`/Pricing). Never name a collection after a locale code or a
   generic page route (no `EnBe`, no `Page`).
-- infer fields from the item shape using the Field Mapping below.
+- infer fields from the item shape using the Field Mapping below, while keeping
+  source-specific constraints and rationale in the plain-text migration plan.
 - push the schema, then create one entry per item.
 - upload each item's image with `fimo assets upload` and store the returned Fimo
   asset URL in the entry's `media` field (never the source URL or a local
   `public/` path).
 - wire the component to render from the collection (Fimo content
   query/primitives) with a seed/empty state. The hardcoded array is removed.
-- record source/generated/imported counts per content type in the manifest.
+- record source/generated/imported counts per content type in the migration
+  plan/report.
 
-Genuinely one-off blocks (a single hero, the footer) stay static. If unsure
-whether a block is a collection, prefer modeling it as one when items share a
-clear repeated shape and could plausibly be edited or extended.
+A genuinely one-off section with no editorial owner may stay in application
+code, but shared chrome - header, footer, navigation, site settings - belongs in
+a singleton content type. If the evidence is ambiguous, preserve the source
+value and record the decision or unresolved question rather than forcing a
+schema merely because a shape repeats.
 
 ## Field Mapping
 
-Use source headers, values, and repeated patterns:
+Choose from source semantics and the editing experience, not the source
+container type. An object or array is not by itself a reason to use generic
+JSON.
+
+- Editor-authored prose, Markdown, HTML, or other portable formatted content ->
+  `richtext`; convert it to the current Fimo richtext contract and render it
+  with the corresponding Fimo primitive.
+- Repeatable editor-authored structures such as FAQs, cards, features, pricing
+  items, testimonials, and page sections -> `blocks`, with nested richtext,
+  media, or references where their semantics require them.
+- Reusable, independently editable categories, tags, authors, and similar
+  concepts -> `reference`, or blocks containing references, only when stable
+  source records or clear independent management prove the relationship.
+- Opaque or unconstrained metadata, third-party payloads, and intentionally
+  non-editor-authored data -> generic `json`, with a concise rationale in the
+  content plan and worker report.
+
+Then use source headers, values, and repeated patterns:
 
 - title/name/heading -> `string`
 - slug/path/url/permalink -> `string`
-- body/content/post/html/description -> `richtext`
+- body/content/post/html/description -> `richtext` when editor-authored prose
 - excerpt/summary/dek -> `text`
-- image/photo/thumbnail/media/asset/file -> `media`
-- date/published/created/updated/event time -> `datetime`
+- image/photo/thumbnail/media/asset/file -> `media`, carrying the source alt on
+  the media value; never add a separate alt field (`references/media.md`)
+- date/published/created/updated -> `date`; use `datetime` only when the crawled
+  values carry a time and a UTC offset, which `datetime` requires
+- event start/end time -> `datetime`
 - price/amount/rating/order/count -> `number`
 - featured/draft/published/enabled/archived -> `boolean`
-- category/tag/author/reference -> `reference` only when verified, otherwise
-  `string` or tag-like text
-
-If unsure, preserve the raw value in the migration artifacts and add a note.
+- repeated section/section stack/nested item list -> `blocks` with one named
+  variant per distinct section shape
+- category/tag/author/related item/shared entity -> `reference` to the content
+  type that models it (see References below)
+- structured data with no Fimo-native equivalent -> `json`, with the reason
+  recorded
+
+Keep media as `media`, including inside blocks, and preserve proven relationship
+targets, direction, and cardinality. Do not turn a fixed enum, application-owned
+taxonomy, or accidental string match into a reference. If unsure, preserve the
+exact raw value in the migration artifacts and record the mapping as unresolved
+or incompatible rather than losing content.
 
 ## Entries
 
@@ -65,33 +145,37 @@ For every content type:
 - preserve slugs
 - preserve SEO title, description, share image, canonical URL when available
 - preserve publish status and dates
-- preserve authors, categories, and tags
+- preserve authors, categories, and tags as references to their content types
+- preserve each media value's source alt text on the media value itself
 - convert rich HTML to the current Fimo rich text representation
 - keep source count, generated count, imported count, and skipped count in the
-  manifest
+  migration plan/report
 
 Do not wire a page to remote Fimo content until the matching schema exists and
 the page has a seed/empty state for local development.
 
 ## References
 
-Create references only when:
-
-- exports contain stable reference IDs
-- repeated values clearly match another exported collection
-- the user confirms the relationship
+Model categories, tags, authors, related items, shared entities, and repeated
+taxonomies as `reference` fields pointing at their own content type. An editor
+picks an entry; they do not retype a string, maintain a list of raw IDs, or edit
+an opaque JSON array. When the source has no schema for that entity, infer a
+clean editor-facing one from the values themselves - a `Category` with `name`
+and `slug` - instead of leaving the value hardcoded.
 
 Use a two-pass import for references:
 
 1. import all referenced entries with source IDs and slugs
 2. resolve reference fields to target IDs/slugs
 
-If reference confidence is low, keep a string/tag field and record an unresolved
-item.
+The source still bounds the model. A repeated value is proof of a shared entity;
+it is not proof of a link the source never makes. Keep free text that has no
+shared identity as a string, and leave an unproven relationship unresolved with
+an owner action rather than synthesizing an ID.
 
 ## Skips
 
-Skipped fields or entries require a manifest note with:
+Skipped fields or entries require a note in the migration plan/report with:
 
 - source location
 - reason

package/assets/skills/fimo-migration/references/decision.md

@@ -0,0 +1,72 @@
+# Migration decisions
+
+Migration decisions are plain text. Put them in
+`.fimo/migration/migration-plan.md` and the relevant worker report. Do not
+create `.fimo/migration/decision.json`, a target metadata file, or a second
+decision registry.
+
+The decision must say, in ordinary language:
+
+- what the source construct is;
+- where it is proven in the source;
+- whether it becomes collection content, a single, a label, or
+  application-owned code;
+- which schema/payload and consuming files are involved;
+- what was preserved, replaced, or left unresolved; and
+- who or what must do the next action.
+
+The owning worker may write schemas, content payloads, entries, assets, singles,
+and labels directly through the normal Fimo CLI/API contracts. The text plan is
+the handoff; it is not an approval queue and it is not required to replay a
+completed migration.
+
+## Labels
+
+A label is UI-visible copy presented to a visitor or user: navigation text,
+headings, buttons, form labels, validation and error text, calls to action,
+visible empty states, and visible translated copy.
+
+Do not classify every string as a label. Object keys, route segments, CSS
+tokens, analytics event names, internal identifiers, prices and other data
+values, application settings, and assistive-only attribute text remain in
+application code unless the source proves they are editor-managed content.
+Record the source file and consuming UI for each label.
+
+## Schema decisions
+
+Write the complete valid Fimo schema that the source justifies. For every field,
+decide its Fimo type, requiredness, default, string options, uniqueness,
+locale-sharing behavior, media multiplicity/MIME constraints, and reference
+target/cardinality when the source proves them. The schema JSON is an actual
+Fimo artifact and may be pushed by the content planner; it is not a report
+about the agent's reasoning.
+
+Choose field types from source semantics and editor experience, following
+`references/content.md`: use richtext for portable editorial prose, blocks for
+structured or repeatable editorial sections, media for assets, and references
+for independently managed records proven by the source. Use JSON only for
+opaque or application-owned data that has no Fimo-native model, and record why.
+
+Requiredness and defaults come from the source contract, such as a CMS schema,
+collection configuration, validation contract, or type declaration. A field is
+not required merely because the sampled files fill it. Use only source-declared
+or safe technical defaults such as an empty list, `false`, or absent. Never
+invent human-readable copy as a default.
+
+Preserve the raw value and explain the uncertainty in the text plan when a
+mapping is unclear. Validate every schema against the actual Fimo CLI/content
+schema contract and use its generated clients, renderers, and primitives.
+
+## Mapping rules
+
+- Markdown collections become one content type plus one document per slug.
+- Localized documents become one document with one payload per locale.
+- Local assets referenced by content become media-library uploads, and the
+  content payload references the uploaded asset. Media owns its alt text; do
+  not add a parallel alt field to the content schema.
+- Routes map source route modules to target route modules.
+- References are created only from stable source identity or a confirmed
+  mapping.
+- A custom or executable construct is unresolved only when it genuinely cannot
+  be carried over. Record its exact source location, why it is not portable,
+  and a suggested action. Never silently remove it.

package/assets/skills/fimo-migration/references/forms.md

@@ -1,15 +1,21 @@
 # Forms
 
-Builder form backends rarely migrate directly. Replace simple forms with Fimo
-forms and document complex behavior.
+Preserve the behavior a visitor sees. Replace a form with a Fimo form only when
+Fimo reproduces the source form's user-visible behavior end to end; otherwise
+keep the original integration wired and record what it needs.
 
 ## Classify
 
-Use `fimo-native` when the form is a simple contact, newsletter, lead capture,
-RSVP, quote request, or similar data collection form.
+Use `fimo-native` only when Fimo genuinely reproduces the source form's
+user-visible behavior end to end: a simple contact, newsletter, lead capture,
+RSVP, or quote request form whose submit, validation, and success/error flow a
+Fimo form matches 1:1.
 
-Use `third-party` when the form posts to Mailchimp, HubSpot, Typeform, Formspree,
-Zapier, Airtable, payment providers, or another external backend.
+Use `third-party` when the form posts to Brevo, Mailchimp, HubSpot, Typeform,
+Formspree, Zapier, Airtable, payment providers, or another external backend.
+When the external behavior is not 1:1 reproducible - a Brevo double-opt-in
+newsletter flow, for example - keeping the original integration wired is the
+correct terminal state, not a migration failure.
 
 Use `unsupported` when the form depends on auth, checkout, dynamic pricing,
 multi-step state, file workflows not supported by the current project, custom JS,
@@ -43,6 +49,32 @@ For `fimo-native` forms:
 Do not claim live submission parity until the form has been pushed/imported and
 rendered by the site.
 
+## Definition Versus Wiring
+
+Importing the Fimo form definition and wiring the source form UI are two
+different obligations; report them separately.
+
+- The definition (`src/forms/*.json`, pushed to Fimo) covers what the form
+  collects: fields, options, required flags.
+- The wiring covers the behavior the visitor sees around the form: the source
+  page's markup, conditional pricing, availability rules, client-side
+  validation, and the submit/success/error flow. Preserve that local behavior
+  in the application code where possible; pushing the definition does not
+  migrate it.
+- A third-party integration may be explicitly deferred as an unresolved item
+  with the source action and an owner decision, but a form is never reported
+  as migrated while its local behavior is missing or its integration was
+  silently dropped.
+
+## Credentials And Secrets
+
+Record the credential environment keys a preserved integration needs by name
+(`BREVO_API_KEY`, not its value). Never read secret values or copy them into
+migration artifacts. A missing secret is a user follow-up in the report: the
+integration stays wired, local build, evaluation, and QA checks still run with
+the integration inert, and the behavior is never deleted because its secret is
+unavailable.
+
 ## Unsupported Or Third-Party Forms
 
 Create an unresolved item with:

package/assets/skills/fimo-migration/references/frameworks/nextjs.md

@@ -1,26 +1,182 @@
-# Next.js source inventory
+# Next.js source
 
-Load this reference when the migration source is a Next.js application. This
-reference selects evidence strategies; use the target project's `fimo-code`
+Load this reference when the migration source is a Next.js application or the
+user explicitly chose Next.js as a conversion target. It describes what each
+worker must read in that source; use the target project's `fimo-code`
 framework guidance when implementing the migrated application.
 
-## Inventory
-
-1. Record the installed Next.js and internationalization package declarations.
-2. Identify App Router, Pages Router, or a mixed tree without changing it.
-3. Inspect `next.config.*`, request configuration, middleware or proxy files,
-   navigation helpers, route segments, and message dictionaries.
-4. Keep these claims separate:
-   - dictionary locale candidates;
-   - configured locales;
-   - default locale;
-   - publicly routable locales;
-   - localized pathnames.
-5. When next-intl is declared, load
-   `references/inventory/locales/next-intl.md` and run its bounded strategy.
-6. Record dynamic, imported, remote, or otherwise unproven configuration as
-   unresolved for the locale inventory fan-in.
-
-Use package versions to prioritize likely strategies, not as proof of the
-source shape. Projects backport, customize, and combine conventions across
-versions; accept a claim only when its source evidence supports it.
+A Next.js source stays a Next.js target. Keep the detected router flavor,
+`next.config.*`, middleware, and runtime configuration; do not convert the app
+to React Router or another framework to simplify the migration. When framework
+detection is ambiguous, stop and ask. A non-Next.js source converts to Next.js
+only when the user explicitly chooses it.
+
+## Next.js as a conversion target
+
+When the user explicitly chose converting another framework (for example React
+Router/Vite) to Next.js, the framework conversion worker in
+`references/workers.md` owns the target. It inspects the app tree that
+`fimo migrate init` actually created, keeps that single tree, and rebuilds the
+source routes, 404, redirects, headers, middleware, sitemap/robots/OG
+structure, and locale routing structure inside it. It ports the source's own
+loaders, APIs, hardcoded content, and integrations unchanged; Fimo wiring
+happens later through the content workers. The conversion must pass the
+framework gate before content data and code workers start.
+
+Use package versions to prioritize likely shapes, not as proof of the source.
+Projects backport, customize, and combine conventions across versions; accept a
+claim only when its source evidence supports it.
+
+## Runtime and routes
+
+1. Record the installed Next.js, content, and internationalization package
+   declarations. A data-source package is a retrieval clue for the content
+   worker, nothing more.
+2. Identify App Router, Pages Router, or a mixed tree.
+3. Read `next.config.*`, request configuration, middleware or proxy files,
+   navigation helpers, and route segments before changing them. Map every
+   source route to a target route module, a redirect, or an unresolved item.
+4. Inventory `redirects()`, `rewrites()`, `headers()`, route handlers,
+   middleware, cache/revalidation calls, and provider adapters separately.
+   Preserve each rule until its behavior is replaced and verified. Record the
+   disposition of every rule; do not delete a whole provider file because some
+   rules became redundant.
+
+## Equivalents and hosting boundary
+
+Load the target project's `fimo-code` `frameworks/next` and
+`frameworks/hosting` references before implementing. Use normal Next.js
+equivalents when they fit the accepted contract:
+
+- route modules and route handlers for routes, feeds, negotiated responses, and
+  special text/XML files;
+- `not-found` and `notFound()` for framework-owned 404 behavior;
+- metadata APIs and OG/Twitter image routes for SEO and social output;
+- `redirects()`, `rewrites()`, `headers()`, middleware, or response headers for
+  rules that the chosen runtime actually executes; and
+- Next.js fetch/cache/revalidation APIs only when freshness is an observable
+  requirement rather than copied provider machinery.
+
+These are application-level options, not guarantees that Fimo hosting supports
+every header, redirect, route handler, cache mode, edge API, or middleware
+behavior. Verify the chosen host/runtime. If support cannot be established,
+preserve the existing deployment path or record the behavior unresolved and ask
+the user; do not promise equivalence from code shape alone.
+
+### Port Cloudflare behavior
+
+Do not mark a rule unresolved merely because it came from a Cloudflare Worker:
+port static redirects, rewrites, headers, and asset cache headers to the real
+`next.config.*`, then verify each with a request. Put dynamic behavior in
+middleware or route handlers, and use Next.js cache/revalidation APIs when they
+replace observable freshness. Cloudflare-only Cache API, bindings, `waitUntil`,
+and purge calls need a verified host equivalent or remain explicitly unresolved.
+
+Give every worker rule a `preserved`, `replaced`,
+`safely-unnecessary-implementation-detail`, or `unresolved` disposition with
+its target file and request-level proof.
+
+## SEO, OG, and social
+
+The routes/SEO worker owns the source's existing SEO and social surface:
+`metadata` exports, `generateMetadata`, `opengraph-image.*` and
+`twitter-image.*` route files, dynamic OG image routes built on
+`ImageResponse`, canonical URLs, robots, and sitemap generation. Preserve each
+behavior in place; when one cannot be preserved, record an explicit gap with
+the affected routes instead of shipping pages that silently lost their share
+metadata.
+
+## Build-time and browser runtime
+
+The Next server runtime reads `FIMO_CONTENT_API_URL`; client components and
+generated client hooks read `NEXT_PUBLIC_FIMO_API_URL`. For a local production
+build or migration acceptance run, expose both names and point them at the
+same tenant content URL. `FIMO_API_URL` is the management/CLI API and is not a
+substitute for either content API variable.
+
+`withFimo` derives these aliases during `next dev` when the project is linked,
+so local development does not need hand-written values. A production build,
+however, compiles `NEXT_PUBLIC_*` values into the browser bundle and the
+adapter intentionally does not inject them outside the development phase.
+For `next build`/`next start`, set temporary values in the shell or an ignored
+`.env.local`; never commit secret values. In either mode, exercise at least one
+client-side data read after startup.
+
+## Preview embedding and response headers
+
+Fimo Preview loads the app in an iframe and drives it over the postMessage
+preview bridge, so development/preview responses must let the preview origin
+frame the app.
+
+- `withFimo` consumes `FIMO_PREVIEW_ALLOWED_ORIGINS` (platform-supplied,
+  comma-separated `**.<domain>` patterns) only to extend `allowedDevOrigins`
+  during `next dev`. It does not add, remove, or rewrite response headers;
+  wrapping the config never fixes a framing block by itself.
+- When the source `headers()` sends `X-Frame-Options` or a CSP
+  `frame-ancestors` directive, keep `X-Content-Type-Options`,
+  `Strict-Transport-Security`, and `Referrer-Policy` unchanged, and translate
+  the framing block in the migrated config. For a hosted/remote preview, while
+  `FIMO_PREVIEW_ALLOWED_ORIGINS` is set, omit `X-Frame-Options` and send
+  `Content-Security-Policy: frame-ancestors 'self' https://*.<domain>` derived
+  from each `**.<domain>` entry. For local `next dev`, when the platform
+  variable is absent, omit the framing block only while
+  `process.env.NODE_ENV !== 'production'`; keep the source framing policy in
+  production. Never hardcode a preview provider domain.
+- Record every translated or dropped header in the runtime report's Hosting
+  section.
+
+Without a browser, verify embeddability deterministically: with the variable
+set, request a route from the running dev server and assert the response
+headers carry no unconditional framing block, then mark visual proof
+unavailable in the QA report.
+
+## Locales
+
+Keep these claims separate, and treat any one of them as unproven until its
+source says so: dictionary locale candidates, configured locales, the default
+locale, publicly routable locales, and localized pathnames. A dictionary file
+never proves route reachability.
+
+When `package.json` declares next-intl, the locales worker reads the actual
+message files, `defineRouting` values, middleware, request helpers, and call
+sites directly. A dictionary filename is evidence for a message locale, not
+proof that the locale is routable. If the source uses another library or a
+custom store, follow its imports and reads in the same worker. The worker may
+write a short bounded temporary extractor when that is faster, but it owns the
+interpretation and must record the source evidence and any unresolved claim.
+
+## Markdown, MDX, and inline content
+
+The content planner reads the content itself: file locations and formats,
+frontmatter keys and values, locale-shaped filenames or directories, route and
+component modules that consume them, hardcoded arrays and object literals, and
+local asset references under `public/`. It records every consuming source and
+target module in `affectedFiles` before code workers start. Nested frontmatter,
+mixed locale conventions, missing local assets, and unproven route references
+need a decision from the source, not a guess.
+
+Map what the source proves: a directory of Markdown files with several slugs may
+be one collection, locale-suffixed files may be locale payloads of one
+document, and a `public/` reference may become a media upload. The content
+planner decides the destination from the consuming route and data shape, rather
+than using a filename or extension as an automatic classification.
+
+Create one source item per Markdown/MDX document and per independently handled
+construct inside it. Portable prose and an executable MDX component are
+different items even when they share one file. Read the custom component, its
+import, and its data path; assign it to a code batch when it can be rebuilt with
+native Fimo content, otherwise record it unresolved before data import begins.
+Never remove JSX from the richtext payload without representing that JSX as its
+own migrated or unresolved source item.
+
+For a hardcoded content array, create one source item per object and preserve
+observable order explicitly. The matching data batch count must equal the
+source item count. A schema and query with zero planned entry items is an
+incomplete handoff.
+
+Use a temporary read-only extractor only when it reduces repeated work. Parsing
+frontmatter or a large literal array can be useful; a general Next.js AST parser
+is not required. Record the mapping in the text content plan and worker report.
+
+Content that is not file-backed follows the content planner's discovery branches
+in `references/workers.md`; preserve every provider gap as unresolved evidence.