Change Requests

A Change Request (CR) is a formal record of a proposed code or configuration change, created when a case identifies a novel bug or a recurring issue that requires an engineering fix. NestFleet drafts the change proposal — including a GitHub PR description, affected surfaces, and a risk assessment — and routes it through an approval workflow before any code changes are made.

What a change request is

Change requests bridge the gap between customer-facing support and engineering. Rather than informally filing a GitHub issue and hoping it gets prioritised, NestFleet creates a structured, audited record that captures:

• The originating support case (with full context and customer conversation)
• A proposed fix description generated by the LLM based on the case and codebase context
• Affected surfaces (API, console, worker, database schema)
• Risk assessment: breaking change? Data migration required? Rollback plan?
• The approver's rationale and decision
• The linked GitHub PR (once implemented)
• A full audit trail of every state transition

Change request lifecycle

How a change request is created

Change requests are always created from a case. There are two paths:

1. Automatic — novel bug detection: After triage, if the case is classified as a bug and the known-issue search returns no close matches (no known issue similarity above the novelty threshold), the system automatically creates a draft CR and enqueues the change_prep job.
2. Manual — team-initiated: Any team member with the Operator or Support Lead role can create a CR from any open case by clicking Create Change Request in the case detail view. This is useful for feature requests or recurring issues that don't meet the automatic threshold.

The PR draft

When the change_prep job runs, NestFleet uses the complex LLM tier to generate a structured GitHub PR draft. The draft includes:

• Title — a concise, conventional-commit-style PR title
• Problem statement — a clear description of the bug or gap, grounded in the customer's report
• Proposed solution — a high-level description of the fix (not implementation code)
• Affected surfaces — which parts of the system are touched (e.g. API route, DB migration, console UI)
• Risk assessment — breaking change risk (none / low / medium / high), data migration required (yes/no), suggested rollback approach
• Test checklist — what tests should be written or updated

Once approved, the Change Lead or engineer can push the PR draft to GitHub as a pull request with the Push to GitHub button. NestFleet uses the configured GitHub App to open the PR in the product's repository with the draft text pre-filled.

Approval workflow

Only users with the Change Lead role can approve or reject change requests. This separation of duties ensures that AI-generated change proposals always pass through a qualified human reviewer before any code work begins.

To approve a CR:

1. Open the CR from the Change Requests list or from the originating case
2. Review the PR draft, affected surfaces, and risk assessment
3. Enter an optional rationale note (required if rejecting)
4. Click Approve or Reject

The approval decision, rationale, and approver identity are recorded as an audit event with a timestamp. This creates a permanent, tamper-evident record of who decided what and why.

Rejection

When a Change Lead rejects a CR:

• The CR state moves to rejected
• The originating support case receives a note with the rejection rationale and moves to awaiting-lead
• An audit event is logged
• The team member who created the CR is notified by email

A rejected CR can be re-submitted after revision if the underlying case changes (e.g. the bug becomes more severe or a different root cause is identified).

Infrastructure debt CRs

Not all change requests originate from customer cases. NestFleet supports a sidecar CR type for infrastructure debt, tagged with cr_track: infra_debt. These are created manually by engineers to track security patches, dependency upgrades, or architectural improvements that were identified during normal case work but are not tied to a specific customer report.

Infrastructure debt CRs go through the same approval workflow but are listed separately in the Change Requests view under the Infra Debt tab.