/fizz-sync

name: fizz-sync
description: Reconcile an existing Fizz harness with a changed source tree. Detects added/removed/changed contract functions, quarantines stale properties, regenerates drifted handler stubs, and refreshes the snapshot. Trigger on "fizz-sync", "resync fuzzing", "sync fuzz harness", "refresh fuzzing properties", "fuzzing drift check".

Fizz Sync Skill — fizz-sync

Reconcile a project previously processed by the **Fizz** skill with a changed source tree. This is the re-use entry point: after the user modifies Solidity sources, `fizz-sync` detects drift, quarantines stale properties, regenerates drifted handler stubs, and refreshes the snapshot — WITHOUT re-running the full 11-step pipeline.

When to use

• The source contracts under `src/` changed since `fizz` last ran.
• A property in `PROPERTIES.md` fails to compile or references a function that no longer exists.
• The user added new external functions they want fuzzed.
• The user wants a "is anything stale?" health check before re-running a campaign.

Parameters

• `SUITE_DIR`: Solidity suite directory relative to project root (default: `test/fizz`). Use the same value that was passed to the `fizz` skill when the harness was generated.
• `META_DIR`: Metadata directory relative to project root (default: `fizz_data`). Use the same value that was passed to the `fizz` skill.

Arguments

• `--init` — one-time bootstrap: create `{META_DIR}/last-run.json` from the current state. Use this the first time fizz-sync runs on a project (or when adopting fizz-sync on a project that was fuzzed before the snapshot format existed).
• `--only <Contract>` — scope the sync to a single contract name.
• `--apply` — actually perform the automatic fixes. Without `--apply`, fizz-sync runs in dry-run mode and only reports drift.
• `--no-property-quarantine` — skip the property quarantine phase (useful if the user wants to handle stale properties manually).

The default (no flags) runs a dry-run drift report.

Preconditions

• The project must have been processed by the `fizz` skill at least once. Look for:
• `{PROJECT_ROOT}/{META_DIR}/contracts.json`
• `{PROJECT_ROOT}/{META_DIR}/entry-point-selection.json`
• `{PROJECT_ROOT}/{SUITE_DIR}/` (suite directory)
• If any of the above are missing, stop and tell the user to run `fizz` first.

---

STEP 0: REBUILD CURRENT ABIS

The snapshot diff compares against `contracts.json` and `entry-point-selection.json`. Those files reflect the state from the last `fizz` run, NOT the current source tree. You must refresh them first.

Run sequentially:

1. `cd {PROJECT_ROOT} && forge build --skip 'test/**/*.sol'`

The `--skip` flag is critical: if the user's source change broke downstream call sites in `test/`, a plain `forge build` will fail on the harness code — which is exactly the drift fizz-sync is supposed to fix. Skipping `test/` means we only validate that the SOURCE compiles cleanly, which is all we need to refresh the ABI.

If the build still fails with `--skip 'test/**/*.sol'`, the source itself has a compile error. Stop and report it. Fuzz-sync cannot proceed without valid source artifacts.

2. `node {SKILL_PATH}/../../scripts/extract_abis.js {PROJECT_ROOT} --meta-dir {META_DIR}`

This refreshes `contracts.json` from the latest artifacts. It overwrites the old file in place.

3. **Do NOT re-run `select_functions.js` automatically.** The existing `entry-point-selection.json` encodes the user's prior tier assignments and selection choices. fizz-sync treats it as the source of truth for what's "in scope" and diffs only within that scope.

If new contracts have been added that the user probably wants to fuzz, the drift report will surface them and the user can manually add them to `entry-point-selection.json` and re-run fizz-sync.

---

STEP 1: HANDLE --init

If the user passed `--init`:

1. Run:

   node {SKILL_PATH}/../../scripts/fizz_sync.js {PROJECT_ROOT} --init

2. If the script reports the snapshot already exists, ask the user whether they want to overwrite with `--force` (they usually do NOT — it would erase drift history).

3. Report the number of contracts and properties captured, then stop. No further steps.

---

STEP 2: RUN THE DRIFT REPORT

Run:

node {SKILL_PATH}/../../scripts/fizz_sync.js {PROJECT_ROOT}

The script:

• Reads `{META_DIR}/last-run.json` (created by `--init` or by Step 11 of the main `fizz` skill).
• Builds a fresh snapshot from the current `entry-point-selection.json`, source file hashes, and `PROPERTIES.md`.
• Diffs them and writes `{META_DIR}/sync-report.json`.
• Prints a human-readable summary.
• Exits 0 if no drift, 1 if drift was detected.

If exit 0 and no drift, stop and tell the user the harness is already in sync.

Read the JSON report:

{PROJECT_ROOT}/{META_DIR}/sync-report.json

The JSON schema is:

{
  "generatedAt": "...",
  "hasDrift": true,
  "contracts": {
    "added":          [{"name":"...", "sourcePath":"...", "functions":[{"signature":"...", "tier":"primary"}]}],
    "removed":        [{"name":"...", "handlerFile":"...Handler.sol"}],
    "changed":        [{"name":"...", "functionsAdded":[...], "functionsRemoved":[...], "functionsChanged":[{"oldSignature":"...","newSignature":"...","handlerMethodName":"..."}], "tierChanged":[...]}],
    "sourcesChanged": [{"name":"...", "sourcePath":"..."}]
  },
  "handlers": {
    "orphan":   [{"file":"...", "contract":"..."}],
    "modified": [{"file":"..."}],
    "missing":  [{"file":"..."}]
  },
  "properties": {
    "referencingRemoved": [{"file":"...", "reference":"lender_oldMethod", "reason":"..."}],
    "fromSnapshot":       [{"id":"GL-01", "checkbox":"x", "functionName":"property_..."}]
  }
}

Use this object as the canonical work list for the rest of the skill.

---

STEP 3: DRY-RUN SUMMARY (ALWAYS)

Regardless of whether `--apply` was passed, print a concise summary to the user that mirrors the report:

fizz-sync drift r