shuishen
17 hours ago 385be2eca72eb3833efa4be0a0088b34e764788a
AGENTS.md
@@ -29,7 +29,7 @@
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.
@@ -39,8 +39,10 @@
- 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.