FAQ & troubleshooting

No. Claude Code is the native path, but the skills format is an open standard several other tools read directly, see the compatibility page for exactly which of the 8 checked tools need zero setup, a placement step, or an explicit enable step. Any MCP-speaking client can also reach Refract's deterministic tools directly, regardless of Skills-format support.

It shouldn't ask more than a handful, and only the ones that change what gets generated. ftc-team-config runs a deterministic extractor over your repo first and only asks about what code genuinely can't answer. Once confirmed, it isn't asked again.

ftc-team-config establishes and confirms what your robot is, it never writes code. ftc-construct writes the actual code once a config is confirmed, and hands back to ftc-team-config if it isn't.

The shipped data reflects DECODE specifically, but the architecture is built to carry forward, see the architecture page's note on the core-model/season-extension split. A season transition replaces one file, not the whole system.

The skills read your repo locally and read Refract's own bundled reference data, both local operations. The MCP server subprocess-calls local scripts; it doesn't call out to any external service on its own. Whatever LLM you're using handles requests the same way it does for any other task in that tool.

Say so. Every value is source-cited (a URL and a retrieval date for hardware/library specs, a rule ID and tagged manual text for legality verdicts), so a wrong value is checkable and fixable at the source. This is exactly the kind of report this project treats as a real finding, not noise.

ftc-rule-check checks the corpus's stored Team Update number against a live fetch of the manual page before answering. If that live check fails, the verdict still comes back, with that caveat attached, not silently dropped.

Yes, refract-suite/ftc-shared-foundation/references/ holds the library docs (each file source-cited with a fetch date), and the hardware-lookup catalogs directory holds the hardware catalog (each value source-cited). Nothing in either is generated; both are meant to be spot-checked against their own cited sources.

Confirm the skill files are actually where your tool scans, per-tool paths differ (see compatibility). Confirm your tool's version is current, several zero-config paths are relatively recent additions. Try asking more directly, a skill triggers off its own description matching what you asked.

This shouldn't happen. Check team-config.yaml at your project root, the field should show confirmed: true. If it shows false or is missing, something reset it rather than the skill re-deciding to re-ask on its own.

By design: if generation_allowed isn't true on your team-config.yaml, ftc-construct hands back to ftc-team-config instead of guessing. Run validate_config.py, its unconfirmed_mandatory list names exactly what's still open.

Both are real, valid outcomes, not something broken. UNVERIFIABLE means the live freshness check couldn't confirm the corpus is current, the verdict itself still stands, with that caveat attached. ambiguous means the retrieved rule text genuinely doesn't resolve the question either way.

Confirm dependencies installed (pip install -r mcp-server/requirements.txt), confirm the server runs standalone, then run the fidelity test python3 mcp-server/test_server.py. If that passes, the issue is in your client's MCP config, a wrong path or a missing python3 on PATH are the two most common causes.

Deliberate, not a bug, the part genuinely isn't in the seeded catalog. The abstention reason names the exact missing artifact. If you have the real spec, it's worth reporting as a real catalog gap.

Report it. Every claim here is checked against something real as of when it was written. Tools update their own behavior; if something has drifted since, that's a real, useful finding.