Maintenance Reports

What are maintenance reports?

Bundle the issues handled in a project into calendar-period (weekly/monthly) documents your client can actually read. Published reports never change, so they serve as evidence for maintenance billing, monthly reporting, and contract renewals.

What goes into a report

• Plain-language summaries per issue — Each issue described in the client's language, not developer jargon. AI drafts the summary; a human reviews and edits before publishing.
• Resolution timelines — State transition history from intake to verification.
• Commit links — Actual fix commits collected via commit key integration.
• Public comments — The public conversation with your client.

Publishing flow

1. Pick a period — Choose a weekly or monthly calendar period, and the issues received/handled in it are assembled automatically.
2. Edit the draft — Adjust per-issue summaries and wording freely until you publish.
3. Publish — The content is frozen as a snapshot at publish time. Verified issues transition to Reported (closed) upon publishing.
4. Share — Send the public link to your client, or save as PDF from the print-friendly view.

Immutability and corrections

• A published report never changes, even if issues are edited afterwards.
• When content must be fixed, publish a correction as a new version. Previous versions and correction history are preserved together.
• This immutability is what lets you use reports as "exactly what was reported at the time" evidence, even in disputes.

An honest note about scope

Reports are assembled from issues filed in QA Note. Work that came in by phone or messenger and was handled on the spot isn't included automatically — add it as a manual issue within the period if needed.