| | |
| | | 1. Read the root documentation, `PROJECT_CONTEXT.md`, and the target capability README. |
| | | 2. Classify the capability as A, B, or C and identify the exact role of `geoai-py`. |
| | | 3. Define a runnable Demo with real input, inspectable output, structured metadata, and measurable acceptance criteria. |
| | | 4. Inspect hardware and existing environments before installing dependencies. Default to CPU because no NVIDIA CUDA is available. |
| | | 4. Inspect hardware and existing environments before installing dependencies. Keep a CPU-compatible route for every supported workflow. Use CUDA only for model or vision computation that benefits from it and only after the fixed capability environment passes a probe; file I/O, data preparation, geometry/export steps, and the console remain CPU unless separately validated. |
| | | 5. Validate one normal and one difficult representative sample before running a full directory. |
| | | 6. Visually inspect generated images, maps, documents, or spreadsheets. |
| | | 7. Record model, package, dataset, and weight licenses independently before suggesting commercial use. |
| | |
| | | |
| | | - Prefer existing project patterns and `geoai-py` APIs over new abstractions. |
| | | - Do not start, control, or use a browser to inspect local-console visual output. For UI, map, image, or 3D-model visual acceptance, state the exact view or interaction that needs checking and ask the user to provide screenshots; use non-browser build, HTTP, artifact, and automated tests independently. |
| | | - Run `npm run build` only after Vue/TypeScript/CSS or build-time client configuration changes. Do not rebuild for data processing, result discovery, or server-only changes. |
| | | - Preserve geospatial coordinates only when the input has a valid CRS and transform. Ordinary JPEG results remain pixel coordinates. |
| | | - Report false positives, misses, runtime, and unsupported classes honestly. Do not hide limitations by lowering thresholds. |
| | | - Do not batch-run large datasets until a representative validation indicates that the approach is suitable. |
| | | - Do not delete or overwrite source imagery, model weights, results, or unrelated user changes. |
| | | - For a console result-removal feature, derive an explicit deletion plan on the server from a discovered, console-owned artifact. Require confirmation before removal; never accept a browser-supplied path, and preserve `baseData`, external inputs, validation/baseline assets, and unrelated runs. |
| | | - Do not commit unless the user explicitly asks. |