/fizz-convert

name: fizz-convert
description: Convert English-language properties in PROPERTIES.md (produced by the Fizz skill) into Solidity assertions inside the existing fuzz harness, then flip their checkboxes. Trigger on "fizz-convert", "convert properties", "implement properties from PROPERTIES.md", "convert PROPERTIES.md to Solidity".

Property Conversion Skill — fizz-convert

You are an expert Solidity fuzzing engineer working inside a project that was set up by the **Fizz** skill. Your job is to convert English-language properties in `PROPERTIES.md` (project root) into Solidity code inside the existing harness, then flip their checkboxes from `[ ]` to `[x]`.

**Arguments**: optional space-separated property IDs (e.g., `GL-01 SP-03`) passed when the user invokes the skill. If no IDs are given, convert ALL properties currently marked `[ ]`.

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.

Checkbox states and how they map to actions

`PROPERTIES.md` uses three states. The action you take depends on BOTH the current checkbox AND whether tagged Solidity for that Spec ID already exists in `Properties.sol` / handlers.

**Tagged Solidity** = a function whose natspec starts with `/// @notice <ID>:` (e.g. `/// @notice GL-05:`). The implementer agents are required to emit this doctag for every property they write, so it is the canonical way to find the existing code for any Spec ID. Search both `{SUITE_DIR}/Properties.sol` and every file under `{SUITE_DIR}/handlers/`.

Action matrix:

| Current checkbox | Tagged Solidity exists? | Action | |---|---|---| | `[ ]` | NO | **Implement fresh.** Normal pending case. On success → `[x]`. On infeasible/skip → `[-]`. | | `[ ]` | YES | **Regenerate.** The user manually downgraded `[x]`→`[ ]` because they want it re-implemented (description changed, prior impl was wrong, etc.). Delete the existing tagged function AND any handler call sites (for `SP-*`), then implement fresh as if it were the row above. On success → `[x]`. | | `[x]` | YES | **Skip.** Already implemented. Never re-implement, never overwrite. If the user explicitly listed this ID in arguments, warn and skip. | | `[x]` | NO | **DRIFT — stop and warn.** The spec claims it's done but no tagged Solidity exists. This means either the user deleted the function manually without updating PROPERTIES.md, or the doctag was lost. Do NOT silently rewrite the spec. Print a warning naming the ID and ask the user to either restore the function, flip the checkbox to `[ ]`, or flip it to `[-]`. Skip this ID for the rest of this run. | | `[-]` | NO | **Leave alone.** Manual / do-not-touch. Never read as a target, never flip, never write Solidity. If the user explicitly listed a `[-]` ID, refuse and tell them to flip it to `[ ]` first. | | `[-]` | YES | **Drop.** The user manually downgraded `[x]`→`[-]` because they want the property removed entirely. Delete the existing tagged function AND any handler call sites (for `SP-*`). Leave the checkbox as `[-]`. Report under "Dropped" in the summary. |

**Hard rule**: never modify a `[x]`+YES line and never flip `[x]`→anything automatically except as part of a build-failure rollback for a property you generated in the same run.

---

STEP 1: READ CURRENT STATE

Read in parallel:

1. `PROPERTIES.md` (project root) — the source of truth for what needs to be converted 2. `{SUITE_DIR}/Properties.sol` — where property functions live 3. `{SUITE_DIR}/Base.sol` — for the `Ghosts` struct, `actors` array, `NUMBER_OF_ACTORS`, available contract instances 4. `{SUITE_DIR}/Snapshots.sol` — for the `State` struct, `stateBefore` / `stateAfter`, and `_takeSnapshot` 5. `{SUITE_DIR}/handlers/` — every handler file, to see existing function names, `snapshotBefore()` / `snapshotAfter()` placement, and ghost update conventions 6. `{META_DIR}/property-plan.md` if it exists — for the ghost/snapshot/wiring tables that back each Spec ID 7. The relevant in-scope source contracts (only the ones referenced by the properties you are about to convert)

If `PROPERTIES.md` does not exist at the project root, stop and tell the user to run the Fizz skill (Step 9) first.

---

STEP 1.5: RECONCILE SPEC WITH CODE

For every Spec ID in `PROPERTIES.md` (regardless of checkbox state), check whether tagged Solidity exists. The doctag pattern is exact:

/// @notice GL-NN:
/// @notice SP-NN:

Grep `{SUITE_DIR}/Properties.sol` and `{SUITE_DIR}/handlers/**/*.sol` for each pattern. Build a single in-memory map: `spec_id → {checkbox, has_tagged_solidity, function_name_if_found, file_if_found, handler_call_sites_if_SP}`.

Then classify each ID against the action matrix above. The four action types are:

• **IMPLEMENT** (`[ ]` + NO Solidity) — process in STEP 4 normally.
• **REGENERATE** (`[ ]` + Solidity) — first delete, then process in STEP 4.
• **DROP** (`[-]` + Solidity) — delete only, no STEP 4 work.
• **DRIFT_WARN** (`[x]` + NO Solidity) — print a warning and skip this ID. Do NOT touch the checkbox.
• **SKIP** (`[x]` + Solidity, or `[-]` + NO Solidity) — no work.

Deletion procedure (used by REGENERATE and DROP)

For a Spec ID whose tagged Solidity must be removed:

1. **Locate the function block** in `Properties.sol`. Start at the line `/// @notice <ID>:` and read upward to capture any preceding `///` natspec lines that belong to the same block. Read downward through the function signature and body until the matching closing `}` at the function's brace depth. Delete the entire span (natspec + signature + body), plus any single blank line immediately following. 2. **For `SP-*` only**, scan every file under `{SUITE_DIR}/handlers/` for call sites of the deleted function name. The grep target is the bare function name