vibe-to-verifiedlisted

# Vibe to Verified Translate a rough idea into a small change that can be inspected, tested, previewed, reversed, and closed. Keep the language plain, state assumptions, and avoid inventing framework or service details. ## Shape the idea 1. State the desired outcome in one sentence and name the intended audience. 2. Record constraints: repository or artifact, runtime, data sensitivity, deadline, and what must not change. 3. Turn the outcome into observable acceptance checks. Write how a user, test, or operator will know each check passed. 4. List non-goals and unknowns. Resolve only the unknowns that could change scope or safety; label the rest as unverified. ## Split safe lanes 1. Inspect the repository instructions, current branch, and existing test/preview commands before editing. 2. Create one lane per genuinely independent unit. Give each lane a unique identifier and one non-empty relative file or resource scope. 3. Reject overlapping or nested scopes. Keep shared configuration, schema, integration, deployment, and release work serial unless the project proves it is safe to split. 4. Give every build lane a named integration target and a terminal outcome: merged and wired with evidence, or explicitly abandoned and cleaned up. 5. Keep the coordinator responsible for scope and conflict decisions; return implementation work and evidence to that coordinator. ## Match the existing stack 1. Detect the project language, package manager, framework, and supported runtime f