quick-fix

name	quick-fix
description	Express lane for trivial bugs and tiny changes — skips the full contract ceremony. Use for one-line fixes, copy/CSS tweaks, config changes, dependency bumps, or any change localized to one root cause with no new behavior, instrumentation, schema, or platform. Triggered by `/fix <description-or-bug-link>`. Triages size first and escalates to /contract if the change is bigger than trivial.
requiredScopes	["github:contents:write","github:pull_requests:write"]

Quick-fix (express lane)

Process proportional to risk. Trivial changes get almost no process — fix it, add a regression test if it's testable, open a PR. No behaviors, no instrumentation fields, no perf budgets, no critics, no SLA timer, no launch report. Those exist to de-risk features; a one-line fix doesn't need them.

Target: minutes, not hours.

Step 1 — Triage. Is this actually trivial?

This is the most important step. The express lane is ONLY valid for changes that are:

• Localized to a single root cause / small diff
• In a single repo
• No NEW analytics event needed (a fix reuses existing events; a feature adds them)
• No schema change / migration
• No new platform brought into scope
• Not touching auth, billing, or payment primitives
• Not a refactor spanning many files

If ALL of those hold → proceed on the express lane.

If ANY fail → STOP and escalate:

"This is bigger than a quick fix — it [adds a new event / touches two platforms / changes the schema]. Run /contract new instead so the critics catch the edge cases. Want me to start that?"

Don't force a real feature through the express lane. The triage gate is what keeps the fast path safe.

Edge: is it SO trivial that even this is overkill?

For a literal typo, a single CSS value, or a config flag flip, the fastest path is to just make the edit and commit — you don't even need /fix. Say so: "This is a one-character change; I can just make the edit and you commit it, or I can open a tracked PR via /fix. Which do you want?" Respect that sometimes the right amount of process is none.

Step 2 — Understand the change

If given a bug (description or JIRA/Linear link), fetch it and understand: the repro steps, the expected vs actual behavior, and the likely location. If given a change description, just understand the intent.

Locate the relevant code (Grep/Glob/Read, or GitHub MCP). Confirm the root cause before fixing — a fix for the wrong cause is worse than no fix.

Step 3 — Resolve the stack (same as the Implementer)

Read .manifest/repos.yml + reference/STACK-PROFILES.md to resolve the repo's test/lint/build commands and test idiom. Don't assume a stack. If unresolvable, ask.

Step 4 — Write a one-line fix record (lightweight, not a contract)

.manifest/fixes/<ID>.md — minimal audit trail:

---
id: FIX-042
title: OTP timer doesn't reset when app backgrounded
source: https://your-org.atlassian.net/browse/PROD-1234
type: bug          # bug | tweak | config | dep-bump
repo: flutter
createdAt: 2026-05-20T09:00:00Z
---

## Root cause
Countdown used app-lifetime elapsed instead of wall-clock; backgrounding paused the timer.

## Fix
Switch to wall-clock (DateTime.now() delta) in OtpCountdown.

## Regression test
integration_test/otp_countdown_test.dart — backgrounds the app mid-countdown, asserts the button re-enables based on real elapsed time.

No behaviors / instrumentation / perf / comms / ACs. Just enough to know what changed and why.

Step 5 — Implement + regression test

• Make the fix in the repo's idiom.
• Add a regression test that FAILS before the fix and PASSES after — in the stack's test framework (Playwright/Cypress for web, flutter integration_test, XCTest, pytest, go test, etc.). For a bug, the test should reproduce the bug; for a tweak with no testable behavior (pure CSS), note "no automated test — visual change" in the fix record.
• Run the resolved test/lint/build. Green before opening the PR.

Step 6 — Open the PR

Push, open the PR titled [FIX-042] <title>, body links the fix record and the bug. Include a short before/after and the regression test reference. No AC-coverage table (there are no ACs) — just "fixes , regression test added."

Step 7 — Stop

Tell the user it's ready for review. No SLA timer, no canary ceremony unless the change is risky enough that the user asks for it. For a trivial fix, normal merge + deploy is fine.

What the express lane deliberately SKIPS

• The critics (nothing to verify — no new behavior/instrumentation)
• The SLA timer (no promote step)
• The launch report (nothing new to measure)
• Cycle-time stamping (overkill for a fix)

If you find yourself wanting any of those, the change isn't trivial — escalate to /contract new.

Anti-patterns

• Don't run the full contract ceremony for a one-liner.
• Don't skip the triage gate — a "quick fix" that's actually a feature is how bugs ship.
• Don't skip the regression test for a bug fix (the test is the proof the bug is actually fixed and stays fixed). Pure-visual tweaks are the only exception.
• Don't guess the stack's test command — resolve it like the Implementer does.