Débogage d'exécution

VérifiéSûr

Un playbook pour traquer les bogues d'exécution : panneaux vides, tables manquantes, données obsolètes, échecs de clé étrangère, cartes blanches et plantages de builds figés. Symptôme→cause→correction pour chaque problème.

Spar Skills Guide Bot
DeveloppementIntermédiaire
27/07/2026
Claude CodeCursorCodex
#debugging#sqlite#qt#frozen-build#troubleshooting

Recommandé pour

Synthèse automatique

Playbook de débogage symptôme→cause→correctif pour une application Qt/SQLite/WebEngine, couvrant l'initialisation de la base, le reseed des données, les contraintes de clés étrangères, l'emplacement réel de la base par OS et les pièges des builds figés.

Points forts

  • Tableau symptôme→cause probable→correctif avec renvoi vers la section détaillée, ce qui accélère le triage
  • Donne les chemins exacts de la base utilisateur sous Linux et macOS et explique pourquoi éditer l'arborescence source ne change rien
  • Distingue clairement les causes en checkout source (base non seedée) de celles en build figé (fichier absent de datas / resource_path)
  • Identifie le piège du _SCHEMA_VERSION non incrémenté comme première cause de « mes données ne s'affichent pas »

Limites

  • Très spécifique à cette application : noms de fichiers, version de schéma 45 et structure src/ ne sont pas transposables telles quelles
  • La section 4 sur l'inspection de la base est tronquée dans le document fourni, les commandes complètes n'y figurent pas
  • Suppose une familiarity avec PyInstaller, Qt WebEngine et SQLite ; peu d'aide pour un débutant
Quand l'utiliser

À utiliser dès qu'un bug d'exécution apparaît dans cette application : panneaux vides, carte blanche, données obsolètes après édition des JSON, erreur de clé étrangère ou crash uniquement sur build installé.

Quand l'éviter

À éviter pour des bugs dans une autre base de code, ou pour des questions de conception, de performance ou d'architecture sans symptôme d'exécution identifiable.

Analyse de sécurité

Sûr
Score qualité78/100

This is pure documentation: a symptom→cause→fix playbook for a desktop app. No tools are declared, nothing is auto-executed, and the only potentially destructive action (deleting the app's user DB) is scoped to a documented per-user data file and is accompanied by an explicit warning that it destroys user designs. No secrets are read or transmitted, no remote scripts fetched, no prompt-injection or sandbox-evasion content. Listing it carries no meaningful execution risk.

Points d'attention
  • •Section 4 documents deleting the per-user SQLite DB (or the whole data folder) as a reset step; it is destructive to user designs but explicitly warns to back up / warn the user first, and it is a local, scoped path rather than a system-wide deletion.
  • •Includes example shell commands (sqlite3) for local inspection only — no curl|sh, no network exfiltration, no obfuscated payloads, no safety-disabling instructions.
Comment cette analyse est faite

Exemples

Empty panels on launch
My panels are empty at startup and sqlite3 says "no such table". How do I reinitialise the DB and check that schema.sql is actually bundled in the frozen build?
Seed edits not showing up
I edited data/plants.json but the app still shows the old data after restarting. Why isn't init_db reseeding, and what do I need to bump?
FK failure after adding a seed step
I get "FOREIGN KEY constraint failed" after adding a seed step that inserts plant_uses rows. How do I run it inside the FK-off window in init_db?

name: debugging description: Use when chasing a runtime bug — empty panels or "no such table", stale seed data after editing data/*.json, FK constraint failures, a blank/white map, dead network features, or frozen-build-only crashes. Symptom→cause→fix playbook plus where the real user DB lives per-OS, how to inspect it, where Qt warnings and JS console output go, and the SSL/resource-path traps specific to this app.

Debugging playbook

Start from the symptom. Each row links to the detail section below.

| Symptom | Most likely cause | Fix | |---|---|---| | Empty panels / sqlite3 ... no such table | DB not initialised, or a bundled data file not found in a frozen build | Reinit DB; confirm resource_path + .spec datas (§1) | | Edited data/*.json but the app shows old data | _SCHEMA_VERSION not bumped → no reseed on existing installs | Bump the version (§2) | | FOREIGN KEY constraint failed | Insert order / stale row vs FKs-on-at-runtime | §3 | | DB seems to be in the "wrong" place, or edits don't take | Looking at the source tree, not the per-user data dir | §4 (per-OS paths) | | Blank / white map area | Web assets not found, or WebEngine can't render | §5 | | No plant photos / no elevation / OSM import empty | Missing CA certs (SSL) or offline with no fallback | §6 | | Works from source, crashes only when installed | Frozen-build resource resolution / missing hidden import | §7 |


1. Empty panels / "no such table"

Two distinct causes:

  • Source checkout: the DB was never seeded. init_db() (src/db/plants.py) is idempotent and runs on first GUI launch and on the first facade call. Force it: python3 -c "from src.db.plants import init_db; init_db()". Then inspect (§4).
  • Frozen build: a bundled data/schema file isn't found. The file must be (a) listed in scripts/packaging/permadesign.spec under datas, and (b) read via src/resources.py resource_path(...), never a __file__-relative join. This exact bug once produced "No such file: schema.sql" on installed builds; tests/test_resource_path.py guards it.

2. Stale seed data after editing data/*.json

init_db() only reseeds when it decides needs_reseed — which is count < 100 or current_version < _SCHEMA_VERSION. So editing seed JSON without bumping _SCHEMA_VERSION (src/db/plants.py, currently 45) means existing installs keep the old rows: the version check is the only trigger that fires the reseed on a populated DB. This is the #1 "my data change didn't show up" cause. See the schema-change and seed-data skills. To force it locally, bump the version, or just delete the user DB (§4) so the next launch reseeds from scratch.

3. FK constraint failures

FK enforcement is ON at runtime (get_connection sets PRAGMA foreign_keys = ON) but temporarily OFF during the bulk reseed. This matters because Python 3.14 enforces FKs at statement time rather than at transaction commit, so seeding a child row before its parent would fail mid-reseed; the reseed path disables FKs for the duration and re-enables after. If you hit a FK error:

  • In normal operation: you're inserting a child (e.g. a plant_uses / plant_fauna row) whose parent id doesn't exist. Insert the parent first, or fix the id.
  • During a reseed you wrote: make sure your new seed step runs inside the FK-off window in init_db, following the existing _seed_* helpers.
  • If you added a dependent table, it must also be added to the reseed wipe list in init_db or it accumulates stale rows across reseeds (see schema-change).

4. Where the real user DB lives (per-OS) + inspecting it

The single source of truth is src/user_paths.py. The per-user data folder is <base>/Site & Pattern/, where <base> is:

| OS | Base | Full DB path | |---|---|---| | Linux | $XDG_DATA_HOME or ~/.local/share | ~/.local/share/Site & Pattern/permadesign.db | | macOS | ~/Library/Application Support | ~/Library/Application Support/Site & Pattern/permadesign.db | | Windows | %APPDATA% | %APPDATA%\Site & Pattern\permadesign.db |

Notes:

  • The filename stays permadesign.db (internal legacy name — deliberate).
  • The folder was PermaDesign before V1.69 and is renamed once, in place, on first launch (user_paths.migrate_legacy_into). If a migration half-happened, you may see both folders; the code no-ops if the target already exists.
  • Never put the DB in the source tree — tests/test_polycultures.py asserts against it.

Inspect it (Linux example):

sqlite3 "$HOME/.local/share/Site & Pattern/permadesign.db" \
  ".tables" "SELECT COUNT(*) FROM plants;" "PRAGMA user_version;"

PRAGMA user_version is where the schema version is stored (_get_schema_version / _set_schema_version); compare it to _SCHEMA_VERSION in src/db/plants.py to see whether a reseed is pending.

Reset to clean state (destroys the user's designs in that DB): delete the permadesign.db file (or the whole Site & Pattern folder) — the next launch recreates and reseeds it. Warn the user first; saved .perma.geojson project files elsewhere are unaffected.

5. Blank / white map

The map is Leaflet inside QWebEngineView (src/map_widget.py), loading html/map.html + the six html/map/*.js files. Causes:

  • Web assets not resolved in a frozen build — same resource_path / .spec datas issue as §1, but for html/.
  • WebEngine can't initialise (missing system libs / sandbox). Run from a terminal (§7) to see the Chromium error.
  • A JS error broke page init. See "seeing JS output" below.

Seeing JS console output / renderer errors: src/map_widget.py routes the embedded page's console.* messages into Python (javaScriptConsoleMessage on the page). Run the app from a terminal and watch stdout/stderr. See the map-frontend skill for the bridge and console routing detail.

6. Network features dead (photos / elevation / OSM / climate)

Offline-first is by design — the app must degrade gracefully — so a dead feature is usually certs, not logic:

  • macOS Pythons and frozen builds ship no root certificates, so every HTTPS fetch fails silently while the Leaflet map (Chromium, own cert store) keeps working. src/ssl_bootstrap.py (ensure_ca_bundle) wires certifi's CA bundle at startup; if it's missing, pip install -r requirements.txt so certifi is present, then rebuild if packaging.
  • Genuinely offline: fetches fall back to DB-cached results and the data/*_fallback_prairie.json regional defaults. See external-data.
  • In this sandbox, outbound HTTPS goes through a proxy — a fetch that hangs is usually waiting on that, not broken code.

7. Frozen build differs from source

  • Run the installed binary from a terminal to see the traceback:
    • Windows: "C:\Program Files\Site & Pattern\SiteAndPattern.exe"
    • macOS: dist/SiteAndPattern.app/Contents/MacOS/SiteAndPattern
    • Linux: ./dist/SiteAndPattern/SiteAndPattern
  • "Missing module": add it to hiddenimports in scripts/packaging/permadesign.spec.
  • Missing data/html: add to datas in the same spec and read via resource_path.
  • See the release-packaging skill and docs/BUILD.md troubleshooting.

Diagnostics quick reference

  • Qt warnings are filtered by a message handler installed in main.py (keeps the console readable); if you're missing an expected Qt warning, that filter is why. Loosen it temporarily while debugging.
  • Typed errors: the facade/domain raise src/errors.py exceptions (ProjectError, AnalysisError, …) rather than popping Qt dialogs — good places to breakpoint.
  • Reproduce headlessly whenever possible via the facade (see agent-api) — it isolates domain bugs from Qt.

Key files

| Path | What | |---|---| | src/user_paths.py | Per-OS data dir + legacy folder migration (source of truth). | | src/db/plants.py | init_db, reseed decision, FK pragma, _SCHEMA_VERSION. | | src/resources.py | resource_path — frozen-build-safe bundled-file resolution. | | src/ssl_bootstrap.py | CA-bundle wiring for headless/frozen HTTPS. | | src/http_utils.py | Shared fetch helpers + timeouts. | | main.py | Qt warning-message filter; app entry. | | src/map_widget.py | Map view; JS console-message routing. | | src/errors.py | Typed exception hierarchy. | | docs/BUILD.md | Troubleshooting section for installed builds. |

Validation

Reproduce the suspected path headlessly, then confirm the fix with the relevant test module (see testing), e.g. after a DB/reseed fix:

python3 -c "from src.db.plants import init_db; init_db(); print('ok')"
python3 -m unittest tests.test_polycultures -v

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/runtime-debugging-playbook-ms2s7bet/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/runtime-debugging-playbook-ms2s7bet' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/runtime-debugging-playbook-ms2s7bet/download' --output '.skill-downloads/runtime-debugging-playbook-ms2s7bet/SKILL.md.part' && mv '.skill-downloads/runtime-debugging-playbook-ms2s7bet/SKILL.md.part' '.skill-downloads/runtime-debugging-playbook-ms2s7bet/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/runtime-debugging-playbook-ms2s7bet/SKILL.md' && test -s '.skill-downloads/runtime-debugging-playbook-ms2s7bet/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/debugging' && cp -R '.skill-downloads/runtime-debugging-playbook-ms2s7bet' '.claude/skills/debugging'

Cursor
test -f '.skill-downloads/runtime-debugging-playbook-ms2s7bet/SKILL.md' && test -s '.skill-downloads/runtime-debugging-playbook-ms2s7bet/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/debugging' && cp -R '.skill-downloads/runtime-debugging-playbook-ms2s7bet' '.cursor/skills/debugging'

Codex
test -f '.skill-downloads/runtime-debugging-playbook-ms2s7bet/SKILL.md' && test -s '.skill-downloads/runtime-debugging-playbook-ms2s7bet/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/debugging' && cp -R '.skill-downloads/runtime-debugging-playbook-ms2s7bet' '.agents/skills/debugging'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/runtime-debugging-playbook-ms2s7bet'

openskills read 'runtime-debugging-playbook-ms2s7bet'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/runtime-debugging-playbook-ms2s7bet/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires