Car or truck that keeps breaking

You are helping me build a vehicle-defect case file I may submit to the
manufacturer, an arbitrator, or a court. Non-negotiable rules:
1. Never state a fact without a primary source I actually possess. A screenshot
   proves only what is visible in it. No reconstructed times, numbers, or quotes.
2. Every count or duration in any output must be computed from the catalogue at
   build time, with an assertion that fails the build on mismatch.
3. Quote documents verbatim or not at all.
4. State facts; never write legal argument into the record.
5. Flag anything that reads as hyperbole, advocacy, or a padded count — including
   things I wrote.
6. If I ask for something that would misstate the record, say so plainly.
7. Keep a running decisions file (append-only) recording every ruling I make, so
   later sessions do not re-litigate them.

Inventory every piece of potential evidence for my vehicle defect claim. Sources to
sweep: my photo/video exports, my documents folder, my email (search the dealer's
name, the manufacturer's name, "recall", "repair", "case #"), and any cloud folders
I give you access to.

For each item record: filename, capture/creation date and time (from metadata where
available — note when the date comes from metadata vs. filename vs. my memory), what
it shows (one factual sentence describing only what is visible/audible), which
problem it relates to, and a stable ID.

Rules:
- Byte-identical and near-duplicate captures: keep one, mark the rest as duplicates
  with a pointer to the kept item. Never delete originals.
- Grade honestly: does the capture demonstrate the defect, merely support context,
  or show nothing usable? I will cut the last group later — your job now is honest
  description, not selection.
- OCR every screenshot (call logs, chat transcripts, app screens) and record only
  the text actually legible in it.
- Videos: note duration, and whether the defect is visible/audible or only narrated.
- Flag items whose capture date conflicts with what they appear to show.
- Do not rename or move any original file. Output a manifest (CSV or JSON) I can
  review, with your duplicate/grade annotations.

Also build the paper side: every repair order (RO), invoice, recall letter,
technical service bulletin, dealer communication, and manufacturer letter. For each:
date, document type, the exact quote of any decisive line (e.g. their stated reason
for a repair, or "could not verify"), and where the original lives.

From the approved inventory (prompt 01), build a single JSON file — the bundle —
that every later artifact will be generated from. Use the shape in
`schema/bundle.schema.json` (adapt fields as needed, but keep: a `timeline` of dated
events, `video`/`photos` catalogues with problem tags, a `componentLedger`, and any
out-of-service stays with start/end dates).

Rules:
- Every entry carries its source: the file it came from, or the document that
  states it. An event with no source does not go in.
- Purchase, each defect report, each repair visit (arrival and pickup dates), each
  recall (federal filing date, the date any stop-sale or "no repair available"
  notice reached dealers, the date the fix reached this vehicle), each manufacturer
  contact, each written communication.
- Compute and store durations (days out of service, days from recall filing to
  repair availability) as code, not as typed numbers. Where a long stay splits into
  "waiting for a remedy to exist" vs. "in repair", compute both parts.
- Anything I told you from memory goes in a `scopeReviewQueue`, not the timeline,
  until a source is found.
- Cross-check dates: an RO's printed dates beat a filename, which beats memory.
  Record conflicts in the entry rather than silently choosing.
- Sanity assertions at the end: no event before purchase; no repair pickup before
  drop-off; every media item's problem tag is one of the declared categories; every
  timeline driveId/file reference resolves.

Then print me: total events by type, total captures by problem, the five longest
out-of-service spans, and everything in the review queue.

From the repair orders in the bundle, build the component ledger: one row per
part/system the manufacturer's dealers touched.

Each row: date range and RO number · component · what was done (replaced /
reprogrammed / reset / inspected) · the dealer's or manufacturer's OWN stated basis,
quoted verbatim from the RO ("internal malfunction", "concern verified, fault codes
stored", "could not verify", "working as designed") · odometer · and the recurrence
column: did the same symptom recur after this work, with the date and catalogue ID
of the recurring capture.

Rules:
- The stated-basis quote must come off the RO text. If the RO is a photo, OCR it
  and verify the quote against the image before using it.
- Recurrence links must point to a specific dated capture or report in the bundle —
  "it kept happening" is not a ledger entry.
- Order rows so the story is visible: repeated work on the same component adjacent.
- Compute the headline sentence from the ledger (e.g. "N repairs to electrical
  systems across M visits since <date>; K of N in the last year") with a build-time
  assertion, and flag if the honest computation is weaker than what I've been
  saying — I need to know that before the other side tells me.

Build the verified contact record between me and the manufacturer/dealers.

Sources, in order of authority:
1. Carrier usage records. Log into my carrier account (or I will export for you)
   and pull call detail as far back as the online window goes. Extract only calls
   matching the manufacturer's and dealers' numbers — look up their published
   numbers, and treat other numbers in the same dealership exchange as "alternate
   DID, same exchange", labeled as such.
2. Older screenshots. Search my inventory for carrier-app or phone call-log
   screenshots that predate the online window. Each row sourced to a specific
   screenshot states ONLY what that screenshot legibly shows — time only if
   visible, duration only if the row was expanded.
3. The manufacturer's own confirmations. Case-opened emails and post-call surveys
   independently document contacts; cross-reference them by date.

Output: a printable extract (title, my line number, date range, count) with one
table for the carrier-window calls and a second table for screenshot-documented
earlier calls, each row citing its source. Include an honest note about what
predates the records and how it is documented instead.

Rules:
- An unmatched number stays unattributed ("no match established — retained for
  completeness"), never guessed.
- Voicemails: a screenshot of the voicemail entry is evidence of the call; the
  audio is better — remind me to export it.
- No call goes in from memory alone.

Also: draft the message I should use in my carrier's support chat asking how far
back call detail can be retrieved and how to request older records, so I can push
past the online window if it matters.

From the bundle, generate a records request document, organized per demonstrated
problem (not one flat list).

For each problem: a heading, the count of recorded incidents, and the full list of
incident timestamps from my catalogue. Exclude documentation screenshots (emails,
apps, paperwork captures) from incident counts — padding a count is the fastest way
to lose a reviewer's trust. Add any reported-but-uncaptured incidents with the
citation to the contemporaneous written report.

The request paragraph asks for:
1. Diagnostic session logs, stored fault memory, and any telematics/CAN data
   covering the FULL CALENDAR DAY of each timestamp (adjacent day too where an
   incident fell near midnight);
2. Complete diagnostic logs from every service visit on this VIN;
3. That any fault appearing in new or historic records be treated as reported by
   me, whether or not I knew to connect it to my complaints.

Do NOT request specific fault codes. Note that video/photo of the listed incidents
is available at full resolution on request.

Deliverables: a clean PDF, and a CSV of every timestamp (date, time, problem) so
their engineers have no formatting excuse. Assert the total count in the header
equals the rows generated.

Build the case homepage from the bundle. Structure, top to bottom:

1. **Banner** — what this is prepared for, with the case number.
2. **Abstract** — four to six sentences, academic-abstract style, visually
   distinct: the pattern of defects, the repair history in one line, the present
   state, and a final line stating plainly what I am asking for and the decision
   date if one is set. I will write or approve every word of this.
3. **The record** — a few paragraphs of dated fact in plain language. Where a term
   could be misread, define it in place (which screen, which part). Where we chose
   not to film or couldn't, say so. No legal vocabulary, no adjectives doing
   argument's work.
4. **Component ledger** — the table from prompt 03, expandable rows.
5. **Timeline strip** — horizontal swimlanes: recalls/bulletins as duration bars
   (filing date → fix available → fix performed, with tick marks for milestones in
   between), out-of-service stays as bars, calls as ticks, my reports and captures
   as ticks. Tooltips carry date/title; clicking opens a modal with the thumbnail,
   detail lines, and an "Open the full document" link.
6. **Exemplar players** — the strongest few videos per problem, grouped by problem,
   each captioned: title, date, and the one contextual fact that matters (e.g.
   "N days after <part> was replaced under <RO>"). Short and factual.
7. **Evidence grid** — every capture and every document as thumbnails with year
   markers, filterable by problem and by kind (car evidence vs. paper). Documents
   visually distinct from captures.
8. **Records-request block** — summary of prompt 05's request with download links.
9. **Download cards** — the case PDF and the records request.

Interaction rules learned the hard way:
- Every document opens ITS OWN full-resolution original (PDF/image) in a new tab —
  host the originals; never link a modal to some other summary page, and never
  make a reviewer squint at a 400px thumbnail.
- Videos: `preload="none"`, poster images, Range-friendly hosting (the worker in
  `site/` handles this) so scrubbing works.
- Every count shown on the page is computed from the bundle at build time, with
  assertions that fail the build on drift.
- Exhibit numbers (see `templates/exhibit-scheme.md`) appear in modals, grid
  captions, and document links, matching the PDF exactly.
- No analytics, no external CDNs, no third-party requests: everything served from
  the protected origin. The access log is the only telemetry.

Before I send anything: screenshot the rendered page (including an open modal and
a player) and show me.

Generate the printable case file from the bundle:

1. Title page/header: vehicle, VIN, case numbers, "prepared for <review>", date.
2. The component ledger on page 1 — a reviewer who reads only one page should hit
   the repair history, their own stated bases, and the recurrence column.
3. The chronological record: every timeline event, dated, each with its exhibit
   number, decisive quotes verbatim.
4. Per-problem sections mirroring the site's grouping.
5. Exhibit index appendix: every exhibit number → date → one-line description, in
   order, with class totals.

Rules:
- Exhibit numbers assigned deterministically (see `templates/exhibit-scheme.md`)
  by code shared with the site build, so the two can never diverge.
- Every computed number asserted at build. Filename includes the month and year.
- Keep it under ~35 pages; the media catalogue is a listing here, not embedded
  images (the site and full-resolution originals carry the media).
- Render via headless browser to PDF; merge the appendix programmatically; verify
  page count and spot-read pages 1, 2, and the appendix before delivering to me.

Attack my complete case package from six perspectives. For each, produce specific
findings with locations, not general impressions.

1. **Sympathetic insider.** You work at the manufacturer and want to approve this
   cheaply and defensibly. What's missing that you'd need to say yes? What would
   you quietly wish the owner had included?
2. **Manufacturer's counsel.** You want an easy no. Find every overstated caption,
   padded count, date inconsistency, unverifiable claim, and internal
   contradiction. Find the thing the owner omitted that you possess and would
   produce. What is your strongest paragraph against this record?
3. **Journalist.** You might cover this. What can you independently verify? What
   smells like advocacy? What would you cut before trusting it?
4. **Another law firm.** You're deciding whether to take this claimant. Does the
   record hold up professionally? What's amateur about it?
5. **Another claimant.** You're using this as a template. What here is specific to
   this case but presented as if it were the method? What would mislead you?
6. **Regulator.** Does anything here belong in a safety-defect report? Is anything
   framed in a way that would embarrass the owner if quoted in a public docket?

Then: consolidate into (a) fixes you can make now, (b) decisions only I can make,
(c) risks we accept knowingly. Apply (a), queue (b), record (c) in the decisions
file.

Prompt:

Redact <document> for scope <A|B>. Method: rasterize each page, draw opaque boxes,
rebuild the PDF from the rasters — never rely on PDF annotation layers, which can
be lifted. After redacting, render every page back to me as images at readable
zoom over each boxed region so I can verify no partial characters leak at the box
edges. List every field you covered and every field you deliberately left visible,
and wait for my approval before the file goes anywhere.

Also sweep the whole publishable set: grep every HTML/PDF/CSV output for my last
names, address, phone numbers, email, account numbers, and (for scope B) VIN and
case numbers, and strip EXIF from every image. Report matches before fixing.

Draft the cover email to my case manager. Requirements:

- First sentence states what I am asking for (repurchase of the vehicle, case #).
- One short paragraph: what the linked site contains and that the same record is
  attached as a PDF. Site URL + the reviewer credential, written plainly.
- Name where the key artifact is ("the component ledger is on page 1").
- Reference the diagnostic-records request as an attachment, one sentence.
- If a legal standard must be named at all, it appears here, once, factually —
  attributed to their own stated position — and nowhere else.
- Answer anything they asked in a previous email that is still open.
- If a decision date exists, close by confirming it.
- No adjectives, no history lesson, no threats. Under 200 words if possible.

List exactly which files I attach and where they are on my machine.