Skip to content

Restore Report Voice While Keeping Source-Correct Corrections

Summary

Rework the corrected reports so they read like technical comparison reports again, not audit memos. The implementation should preserve the current source-backed factual corrections, but remove rubric-like phrasing such as "this correction pass," "the reviewed source set does not support," and similar evidentiary narration unless a narrow qualification is genuinely necessary for accuracy.

Target the following report set as one coordinated style-restoration pass:

  • docs/reports/1_Regulatory_Audit_Report.md
  • docs/reports/2_Planning_Content_Report.md
  • docs/reports/3_Engineering_Content_Report.md
  • docs/reports/4_Maintenance_Protocol_Report.md
  • docs/reports/8_Master2026_Content_Report.md

Use the corresponding backup files in .agents/backup/Reports-root-legacy-2026-04-09/ as the tone/template reference, especially for report 8. Keep the corrected facts, narrower claims, and valid citations from the current versions; restore the narrative report voice from the backup versions.

Key Changes

Report-writing posture

  • Rewrite each target markdown report into backup-style narrative prose.
  • Keep the existing section structures already associated with each report; do not turn them into grading rubrics or correction logs.
  • Integrate factual corrections silently into the body text wherever possible.
  • Use citations/source references as support, not as meta-commentary about the correction process.
  • Remove recurring audit phrases such as:
  • "the source set does not support"
  • "this correction pass"
  • "supported elsewhere in the corpus" when it can be replaced by direct attribution in normal prose
  • "the defensible takeaway is"
  • Keep a claim-qualification sentence only where needed to avoid repeating a previously unsupported statement.

Source and citation handling

  • Re-check the current corrected claims against Sources before rewriting them into narrative form.
  • Preserve narrowed or removed claims where the correction was substantively necessary.
  • If a point depends on broader-corpus support, cite or attribute it in normal report prose instead of presenting it like a grading note.
  • Prefer direct source-backed statements over meta-language about what was removed.
  • For report 8, use the legacy backup as the style baseline and the current corrected version as the factual baseline.

Per-report implementation standard

  • Report 1: restore an executive-summary and rule-comparison voice rather than a source-audit voice.
  • Report 2: restore planning-report tone, with stable narrative treatment of continuity vs. 2026 changes.
  • Report 3: restore engineering comparison tone while keeping the corrected rule/manual distinctions.
  • Report 4: restore maintenance-report tone and keep fallback practice-specific details framed as examples or cited supporting material, not universal Chapter 7/8 holdings.
  • Report 8: explicitly shift back toward the backup synthesis/report style while retaining the corrected Chapter 12/13/14 and NJAC substance.

HTML and publication parity

  • Update the standalone HTML companions for the same five reports after markdown is locked:
  • 1_Regulatory_Audit_Render.html
  • 2_Planning_Content_Render.html
  • 3_Engineering_Content_Render.html
  • 4_Maintenance_Protocol_Render.html
  • 8_Master2026_Content_Render.html
  • Preserve current layout/presentation.
  • Bring visible prose into parity with the rewritten markdown.
  • Clean touched mojibake while editing.
  • Regenerate the matching site/reports markdown, standalone HTML, and built page outputs with python scripts/build_green_guides.py.

Public Interfaces And File Contracts

  • Canonical authored sources remain the docs/reports/*.md and docs/reports/*_Render.html files.
  • Generated outputs remain under site/reports/.
  • No section re-scoping or report-merging: each report keeps its existing purpose and section layout.
  • The backup files are style references only; they do not override corrected source-backed substance.

Test Plan

  • Confirm each rewritten markdown report reads as a narrative technical report, not a correction memo.
  • Confirm each report still preserves the current corrected factual posture against Sources.
  • Spot-check at least several previously corrected claims in each report to ensure the style restoration did not reintroduce unsupported statements.
  • Verify that broad-corpus support, where still needed, appears as normal attribution rather than rubric-style fallback language.
  • Compare report 8 against its backup to confirm the tone is materially restored while the corrected substance remains intact.
  • Verify each standalone HTML file matches the rewritten markdown on all touched passages.
  • Verify touched mojibake is removed.
  • Run the normal site build and confirm the regenerated site/reports outputs reflect the rewritten docs-side sources.

Assumptions And Defaults

  • This is a style-restoration correction pass, not a substantive rollback.
  • Current source-backed factual corrections remain in force unless a fresh source review shows one should be adjusted again.
  • The default rewrite posture is backup-style narrative, not hybrid audit prose.
  • HTML parity and regenerated site/reports outputs are part of the same implementation pass even where the user only named the markdown files.