// Auto-generated from src/ai-service/skills/system/superblocks-migration/references/focused-debug.md
// Do not edit directly - edit the .md file instead
export const content = `# Focused retry playbook

Reference for \`superblocks-migration/SKILL.md\`. Load this **only** when the runtime prompt tells you this is a focused-retry turn.

This is a _retry_ attempt. Earlier runs already tried — and failed — on the APIs currently \`pending\` in the migration checklist. Your job is to finish them. Before writing any code, stop and think about **why** the prior attempt failed for each one and pick a _different_ strategy. Do not repeat the same approach; if the same plan failed twice, it will fail a third time.

## Step 1: pull the prior-failure context

The checklist stores each item's most recent \`lastFailureReason\`. Call \`build_manageChecklist\` with \`action: "get"\` and read the \`lastFailureReason\` for every \`seed_api\` item still \`pending\`. Treat each reason as primary context when choosing your approach for that API.

Only address the APIs surfaced by that query — the rest of the app is already migrated.

## Step 2: debugging checklist (work through this before editing)

- Did the prior attempt misread the integration kind? Re-check \`node_modules/@superblocksteam/sdk-api/src/index.ts\` for the correct factory export.
- Was the YAML using a block construct you skipped (\`conditional\`, \`parallel\`, \`tryCatch\`, \`loop\`, \`variables\`, inline \`javascript\`)? Translate it explicitly instead of bailing.
- Did parameterization fail because a value flows in from a prior block's \`.output\` rather than \`params\`? Bind the right \`ctx.*\` or a local \`const\`.
- Was the item marked \`failed\` because a target file (\`index.ts\`, a stub path) was "missing"? Confirm on disk — create nothing you were not told to create, but do not bail if the file actually exists.
- Was a SQL statement's parameter shape wrong (scalar vs array, pg type cast)? Use \`= ANY($N::<type>[])\` for lists.
- Prefer the **narrowest** rewrite that compiles and preserves behavior. If a full rewrite failed, try converting block-by-block.
- If a documented method compiles but repeatedly fails at runtime, do not keep retrying the same pattern. Run one reload/retest cycle (\`build_reloadFile\`, then \`testApi\`) and then move to the next API. If no other APIs remain, leave a concrete \`failureReason\` describing the runtime limitation.

## Meta-rule override: when the blocker is _information_, call \`askMultiChoice\` — DO NOT mark \`failed\`

The prior run already hit the \`ZERO judgment calls\` rule and marked these items \`failed\`. Repeating that reasoning on every retry is a loop that burns the user's budget and never converges. The user is _right here, right now, watching this turn_. Ask them.

When the missing piece is something a human can supply (the original SQL, which integration to use, the intended output shape, whether a stubbed block can be dropped, etc.), you **MUST** call the \`askMultiChoice\` tool. This is a **tool call** — not a message, not a paragraph, not a list you type into the assistant response. You are not asking in English. You are invoking the tool named \`askMultiChoice\` with a JSON payload of \`{ question, choices }\`.

### Exact rule

1. Before you ever call \`build_manageChecklist\` with \`status: "failed"\` on an item in this retry, you **MUST** have already called \`askMultiChoice\` about it at least once in this turn. No exceptions.
2. If you find yourself typing a sentence like _"What would you like me to do?"_ or _"Please provide the SQL"_ or _"I need more information"_ directly into your response, **stop**. Delete that text. Call \`askMultiChoice\` instead. The tool is the channel. The assistant text is not.
3. The user only sees tool calls — a free-text question from you will sit there unanswered forever and this turn will be wasted.

### How to structure the \`askMultiChoice\` call

- **One call per distinct blocker.** If two APIs share the same missing information (e.g. both need the original SQL that was stubbed out), put them in a single question.
- \`question\`: a short markdown string. Name the APIs in the question so the user knows what they're deciding about. Reference the relevant \`failureReason\` so the user has context.
- \`choices\`: 2 or 3 entries. The first 1–2 should be concrete, actionable suggestions based on the YAML/integration/prior failure (e.g. _"Provide the SQL query for these APIs"_, _"Use integration <name> with a SELECT _ query"\\*). The **last choice** must be the literal string \`Mark these APIs as complete and continue\` — this is the user's escape hatch for APIs they don't need.
- \`selectionType\`: \`"single"\`.

### After the user responds

- If they pick \`Mark these APIs as complete and continue\`: for every API covered by that question, call \`build_manageChecklist\` with \`action: "update"\`, \`itemId: "api_<ApiName>"\`, \`status: "completed"\`. Do not mark them \`failed\`. Move to the next blocker or finish.
- If they provide information (via a concrete choice or a free-text reply that gives you what you needed): use it to finish the translation, emit the TypeScript module, register it if there's an \`index.ts\`, then \`build_manageChecklist\` \`status: "completed"\`.
- Only call \`build_manageChecklist\` \`status: "failed"\` if the user's response explicitly says they cannot help or chose an option equivalent to "skip this one".

### Self-check before you respond

Ask yourself: _did I actually call the \`askMultiChoice\` tool in this turn for any item I'm about to leave unresolved?_ If the answer is no, you have not followed the rule. Call the tool.

## Then execute

Use the per-API procedure in \`SKILL.md\` for the actual translation work, but treat the prior \`failureReason\` as primary context when choosing your approach.
`;
//# sourceMappingURL=focused-debug.generated.js.map