Replace in-repo reports/ packs by consuming mif-docs-plugin, and introduce the RHT-only genres into mif-docs

[zircote]

Summary

Replace the harness's in-repo report-genre packs (packs/reports/*) by consuming
the canonical modeled-information-format/mif-docs-plugin as the genre provider,
so the organization has one genre authority and the harness stops re-implementing
the MIF genre pattern and conformance plumbing once per pack. The boundary is MIF
conformance: the MIF Level-1-to-Level-3 document genres port into mif-docs, while
the non-MIF surfaces (the channel and projection packs, the mifExempt blog
output, and the harness-local extensions) stay in the harness.

Motivation

The harness ships 18 report-genre packs under packs/reports/, each kind: "genre", each carrying its own SKILL.md, evals/, version, and its own
"author a structured document as a MIF artifact" logic (including the duplicated
Mermaid-only figure rule called out in the SVG-figures request). The
mif-docs-plugin is the organization's canonical MIF documentation skill suite:
one skill per document genre over a MIF Level-1-to-Level-3 floor, with a shared
substrate (mif-frontmatter, ears-acceptance-criteria, mif-validate) and an
orchestrator (doc-set-planner). It is already published in the org marketplace
(v0.1.1, SHA-pinned). Both are MIF-backed, so maintaining two parallel genre
engines duplicates the genre pattern, the MIF frontmatter authoring, and the
conformance gate. The goal is to consolidate on mif-docs as the single genre and
conformance substrate.

Overlap analysis (read before scoping: the swap is NOT 1:1)

This is the load-bearing finding. The two genre sets barely overlap:

• The harness packs/reports/* are research and regulated-output formats:
  academic, systematic-review, clinical-submission, nist-sp,
  regulatory-disclosure, compliance-audit, security-pentest,
  market-research-report, humanities-chicago, humanities-mla, legal-memo,
  computing-paper, sustainability-report, trend-analysis, engineering,
  briefing, exec-summary, competitive-quadrant.
• The mif-docs genres are software and product documentation formats:
  the four Diataxis quadrants, arc42-arch-doc, c4-model-diagram,
  google-design-doc, adr, rust-rfc, python-pep, changelog,
  sre-runbook, playbook, prd, feature-spec, ai-architecture-doc, and the
  three Kiro artifacts.
• None of the 18 harness report genres has a one-to-one mif-docs equivalent.
  The nearest adjacency is engineering against google-design-doc or
  feature-spec. A literal delete-and-replace would remove the research
  deliverables the harness exists to produce.

Therefore "replace" must mean consolidate on the engine and migrate the genres,
not drop them. This issue proposes the consolidation and treats the genre
migration as the core work.

The dividing line: MIF document genres port, non-MIF stays in the harness

mif-docs is the canonical authority for MIF-conformant document genres, so the
boundary for what moves is MIF conformance, not "anything under reports/":

• Ports into mif-docs (or its research-genres companion): the MIF
  Level-1-to-Level-3 document genres. The report channel is the harness's MIF
  Level-3 source of truth, so its genre packs are MIF documents and belong with the
  canonical genre authority.
• Stays in the harness (non-MIF, by design):
  • the channel / projection packs under packs/channels/ (book, pdf,
    jats, xbrl, ectd, notebooklm, github-discuss, github-issues,
    diataxis), which render a MIF report into a delivery FORMAT and are not
    themselves MIF document genres;
  • the blog output, which harness.config.json already marks
    mifExempt: true (a Level-1 published projection whose format is orthogonal to
    the Level-3 report);
  • the harness-local extensions (extensions.harness: falsification lifecycle,
    quarantine, session lineage) and the research engine itself (orchestrator,
    dimension and falsification analysts, source chunker), which are not MIF core
    and never were.

In short: the harness keeps the research engine and every non-MIF projection;
mif-docs gains the MIF document genres those projections render. Any
reports/ pack that turns out to be a format projection rather than a MIF
document genre stays in the harness with the other channels.

Proposed approach

1. Consume the plugin. Add modeled-information-format/mif-docs-plugin
   (SHA-pinned, as the marketplace already lists it) as the harness's genre
   provider, and wire the report channel to resolve genres from the plugin's
   skills.
2. Retire the duplicated substrate. Replace each report pack's bespoke MIF
   frontmatter and conformance handling with the mif-docs substrate
   (mif-frontmatter, mif-validate, doc-set-planner), and drop the duplicated
   per-pack figure and MIF rules in favor of the shared ones.
3. Introduce the missing genres into mif-docs. Every harness report genre is
   absent from mif-docs today, so the migration is mostly net-new genre work in
   mif-docs: introduce each as a first-class genre (one skill per genre over the
   MIF floor, with templates/ exemplars, evals/, and mif-validate
   conformance) rather than a harness-local pack. The full list is in the next
   section. They land either inside mif-docs (broadening its scope past software
   documentation) or in a sibling research-genres companion plugin that shares the
   mif-docs substrate. The harness then consumes them like any other genre.
4. Keep harness.config.json outputs[] and packs[] as the control plane.
   Enabling a report genre enables the corresponding plugin skill; the core
   hardwires none.

Genres to introduce into mif-docs (present in RHT, missing from mif-docs)

Each harness report genre becomes a new mif-docs genre wrapping the canonical
industry pattern for its field, the same way the existing mif-docs genres wrap
Diataxis, MADR, arc42 and the rest. None of these exists in mif-docs today.

RHT genre	Industry pattern the new mif-docs genre adopts
academic	IMRaD scholarly paper (Introduction, Methods, Results, Discussion)
systematic-review	PRISMA systematic review and meta-analysis
computing-paper	ACM / IEEE computing paper
humanities-mla	MLA-style humanities paper
humanities-chicago	Chicago-style humanities paper
clinical-submission	Clinical study report / eCTD-aligned regulated submission
nist-sp	NIST Special Publication structure
regulatory-disclosure	Regulatory disclosure filing
compliance-audit	Compliance audit report
security-pentest	Penetration-test report (PTES / OWASP-style)
legal-memo	Legal memorandum (IRAC: Issue, Rule, Application, Conclusion)
market-research-report	Market research report
sustainability-report	Sustainability report (GRI-style)
trend-analysis	Trend-analysis report
competitive-quadrant	Two-axis competitive-quadrant report
engineering	Design / evaluation report (adjacent to google-design-doc but distinct)
briefing	Briefing note
exec-summary	Executive summary

Notes:

• engineering, briefing and exec-summary are the closest to existing
  mif-docs genres and may fold into google-design-doc / feature-spec variants
  rather than standalone genres; decide per genre during migration.
• Each new genre carries the same acceptance discipline as current mif-docs
  genres: templates/good-l1.md at the L1 floor and templates/good.md at its
  target level (gated by check-exemplars), evals/evals.json, and a clear
  anti-trigger that distinguishes it from neighbors.

Acceptance criteria (EARS)

• WHEN a topic selects a report genre, the harness SHALL resolve that genre from
  the consumed mif-docs-plugin (or its research-genres companion), not from an
  in-repo packs/reports/ pack.
• The harness SHALL NOT carry a second MIF frontmatter authoring or conformance
  implementation: report genres SHALL author via mif-frontmatter and validate
  via mif-validate.
• Each genre in the table above SHALL be introduced into mif-docs (or its
  research-genres companion) as a first-class genre, with templates/ exemplars
  and evals/, BEFORE its packs/reports/ counterpart is retired.
• Every migrated research genre SHALL retain its current capability (no deliverable
  type is lost) and SHALL ship exemplars and evals under the mif-docs
  discipline.
• The consumed plugin SHALL be SHA-pinned and attested, consistent with the
  marketplace admission gate.
• bash scripts/verify.sh and the corpus-level scripts/ontology-review.sh SHALL
  stay green after migration, and copier update SHALL still apply cleanly to an
  instantiated clone.

Risks and migration notes

• Capability loss is the central risk. Gate the retirement of each
  packs/reports/* pack on its upstream mif-docs equivalent existing and
  passing, so no deliverable type disappears mid-migration.
• Cross-repo coupling. The harness gains a dependency on an external plugin's
  release cadence; pin by SHA and bump deliberately.
• Versioning. Harness packs are versioned through scripts/bump-version.sh;
  retiring packs and depending on an external plugin changes the version surface.
• copier update safety. Removing packs/reports/* must not break clones
  mid-flight; stage the migration genre by genre.

Open questions

• Do the research genres belong inside mif-docs (broadening it beyond
  software documentation), or in a sibling research-genres plugin that shares
  the mif-docs substrate? This is a naming and scope decision for mif-docs.
• Does the harness consume mif-docs through the org marketplace, a git
  submodule or subdir, or a vendored SHA-pinned copy?
• Which genres, if any, are dropped outright as unused rather than migrated?
• Sequencing against the open ontology-pack epic (Epic: domain ontology-pack expansion — 5 industry-depth ontology packs + ai-spec channel + spec-genre packs #205) and the on-demand
  vendoring work (feat(ontology): on-demand vendoring mechanism — fetch/verify/lock + author-concierge #222, feat(ontology): flip bundled domain packs to a gitignored on-demand cache (+ corpus re-enrichment) #224), both of which touch the pack and consumption
  surface.

Scope

An architectural consolidation along the MIF boundary: the MIF Level-1-to-Level-3
report document genres migrate into mif-docs (rather than disappear), and the
harness stops being a second genre engine and becomes their consumer. The research
engine and every non-MIF surface (the channel and projection packs, the
mifExempt blog output, the harness-local extensions) remain in the harness
unchanged.

---

Opened from issue #226 and moved here as an idea.