Reviewing Changes

Reviewing is where you ensure quality before the agent's work lands in your main branch. Fabriq gives you the tools to make informed decisions — diffs, validation badges, and an audit trail of every action.

What the review screen shows

When you enter the Review stage, you see:

┌──────────────────────────────────────────────────────────┐
│  Feature: add-dark-mode-toggle                            │
│  Stage: Review                                            │
│                                                          │
│  ┌─ Validation ──────────────────────────────────────┐   │
│  │  ● Lint:  Passed (0 warnings)                    │   │
│  │  ● Types: Passed (0 errors)                      │   │
│  │  ● Tests: 4/5 passed (1 known issue)             │   │
│  └──────────────────────────────────────────────────┘   │
│                                                          │
│  ┌─ Changed Files ──────────────────────────────────┐   │
│  │  ☐ src/components/DarkModeToggle.tsx   (+65)    │   │
│  │  ☐ src/pages/Settings.tsx              (+8)     │   │
│  │  ☐ src/styles/theme.css                (+15)    │   │
│  └──────────────────────────────────────────────────┘   │
│                                                          │
│  ┌─ Acceptance Checklist ───────────────────────────┐   │
│  │  ☐ Toggle appears on Settings page               │   │
│  │  ☐ Dark mode persists after refresh              │   │
│  │  ☐ Uses existing Button component                │   │
│  └──────────────────────────────────────────────────┘   │
│                                                          │
│  [Approve]  [Request Changes]                            │
└──────────────────────────────────────────────────────────┘

Key sections:

Section	What it shows
Validation badges	Lint, type check, and test results — green (pass), yellow (warnings), red (failing)
Changed files	Every file created or modified, with line counts
Acceptance checklist	Key requirements from your feature description — check them off

Step-by-step review process

1. Check validation badges first

Validation badges tell you if the code is structurally sound before you read a single line:

Badge	Meaning	Action
🟢 All green	Lint, types, and tests pass	Proceed to read diffs
🟡 Warnings	Non-blocking issues (unused imports, formatting)	Read diffs, decide if warnings need fixing
🔴 Failing	Tests failing or type errors	Consider requesting changes — ask the agent to fix

If tests are failing, the agent probably needs to address something before you invest time in a detailed review.

2. Read through changed files

Click each file to see the side-by-side diff:

Before                         After
────────────────────────────────────────────────
function Settings() {          function Settings() {
  return (                       return (
    <div>                          <div>
      <h1>Settings</h1>              <h1>Settings</h1>
+      <DarkModeToggle />
    </div>                         </div>
  );                              );
}                               }

What to focus on:

• Business logic: Does the code do what you asked for?
• Edge cases: Loading, empty, error states
• Security: Are user inputs sanitized? Are API calls authenticated?
• Consistency: Does the code follow your project's patterns?

What to ignore (the validators handle this):

• Formatting, unused imports, type errors — lint and type checkers cover this
• Test coverage — validation ran already

3. Check against your original description

Compare the agent's output to what you asked for. Open your feature description and check:

• Did the agent build everything you specified?
• Did it add scope you didn't ask for? (Sometimes agents over-engineer)
• Did it follow the constraints? (Existing patterns, specific libraries)

Requesting changes

If something needs to be fixed:

1. Click on the file in the diff view
2. Select the lines that need attention
3. Leave a comment describing what's wrong:
   • "This doesn't handle the loading state — add a loading spinner"
   • "Use the existing debounce utility instead of inlining the timeout logic"
   • "This should use CSS modules, not inline styles"
4. Click Request Changes
5. The agent receives your feedback and revises the code

After the agent pushes fixes, you enter a new review iteration. Repeat as needed.

You: "Use the existing Button component"
Agent: Updates DarkModeToggle to use Button
You: Check diff → looks correct → move to next file

Approving

When you're satisfied:

1. Click Approve
2. Fabriq runs the close pipeline:
   • Promotes key docs to workspace knowledge
   • Creates a feature-history entry
   • Generates a close summary
   • Logs the audit entry
3. The feature is closed

Validation badges reference

Badge	Status	What it checks
Lint	Passed / Warnings / Failed	Code style, formatting, unused imports
Types	Passed / Failed	TypeScript strict mode checks
Tests	N/M passed	Validation test cases (from testability.md)
Bundle	Size within / exceeded	Bundle size impact of the change

Tips

• Review incrementally: Don't wait until the end. Check confirmation prompts during implementation — catching issues early saves rework
• Trust the badges: If lint, types, and tests pass, the code is structurally sound. Focus your review on business logic and design
• You can always roll back: Fabriq keeps a full audit trail. Every change is reversible
• Use the acceptance checklist: It maps directly to your feature description. Checking it off systematically prevents missed requirements

Next steps

• Closing a Feature — what happens after approval
• Working with the Agent — guide the agent, intervene mid-work
• Undoing Changes — revert if needed
• Stage Gates — gates that control stage advancement