Build the incident report generator

Start on branch phase-8/report and read spec design 20. The code lives in report/; first review dependencies #81, #88 and #101 which must be merged. Write the bats and Pester acceptance tests listed, then build the builder fed by quarantine evidence, integrity findings and closed flaws. Done means tests pass: events merge, missing fields show UNKNOWN, secrets removed, no network calls.

Read first

• Design 20, section 3: pipeline
• Design 20, section 4: incident record fields
• Design 20, section 5: output formats and section 6: accuracy rules
• Design 20, section 7: human checkpoints and section 8: acceptance tests
• Design 06, section 5: quarantine, never delete (the evidence the report collects)
• Design 08, section 4: who, when, from where
• Design 09, section 4: track (closed flaws and their times)
• Roadmap, section 4.4: reporting and cleanup
• AGENTS.md: hard rules 1 (no cloud services) and 2 (no secrets or event values in the repository)

Read these before starting. If this issue and the spec disagree, the spec wins; say so in the pull request.

Summary

Build the incident report builder. A Red Team incident report (a write-up of an attack the Red Team carried out) earns points, but writing one by hand is slow and fields are easily missed. The builder gathers every fact the tools already hold, groups related events into one incident, and fills the report template. A person reviews and submits it. The tool never submits a report.

Depends on

• Blocked by #101 (the flaw tracker, for closed flaws and the time each was closed), #88 (integrity findings) and #81 (the persistence sweep, whose quarantine holds evidence).
• Uses the trip log from #107 and the SIEM alerts from #94, when they exist.

Location & Context

• Branch: phase-8/report. Not a module: it is the cross-phase report/ folder (design 20). The folder exists (report/.gitkeep); the code and the report template are new.
• Output is plain text and Markdown, one file per incident, under the report log category (design 20, section 5). How an operator starts it is not fixed in the spec. If it needs a new action in labyrinth.sh and labyrinth.ps1, decide it with Conventions section 3.3 and update the manual, docs/manual/labyrinth.md, in the same commit.
• Tests: tests/report/ (new; bats and Pester).

Current Behavior

Incident reports earn points but take long to write by hand, and fields are easily missed.

Plan

1. Build the report builder, fed by quarantine evidence, integrity findings and the tracker's closed flaws.
2. Follow the pipeline in design 20, section 3: collect the facts on the host, correlate events within a time window that share an address, account or host into one incident, then draft. Steps 5 to 7 (review, submit, track) stay with people.
3. Build the template from the required fields in design 20, section 4. Show a field with no evidence as UNKNOWN. List every required field still UNKNOWN or empty each time the draft is shown, and once more when the lead marks it ready.
4. Remove passwords, keys and tokens from log excerpts. State the last hop, not the true origin, unless the origin is confirmed. Make no guess about attribution, intent or tool names.
5. Produce a short paste block sized for a portal text field, and a one-page timeline.
6. Track each report's status (draft, submitted, accepted) so nothing is filed twice or forgotten.
7. Make no network call during report generation.

Acceptance tests

Write these first, in bats and Pester:

• A decoy trip in the lab produces a draft with correct time, host, source address and evidence.
• Two related events within the window merge into one incident.
• A missing field is shown as UNKNOWN, never blank or guessed.
• Secrets planted in a log line are removed from the report.
• No network call is made during report generation.
• Every field Rule 9.4 lists has a place in the template, and a draft with an unfilled required field shows the completeness warning before it is marked ready.

Done when

• The Linux and Windows versions both pass CI, including the real-host tests on the Ubuntu and Windows Server runners.
• The manual and the help page for the report command are written.
• The tests above pass in the lab (docs/lab/README.md).

Out of scope

• Submitting a report. A person does that, in the channel the officials give.
• The remediation plan and the confidence notes, which a person writes.
• The trip log and the decoys: #106 and #107.
• Enrichment from outside services, such as address reputation lookups. Never done.