# GeoAI Workbench Instructions

## Scope

These instructions apply to the entire repository at `E:\AllWorkProject\geoai-workbench`.
Read `PROJECT_CONTEXT.md` before planning or changing a capability.

## Project Definition

- In this repository, GeoAI means workflows based on `opengeos/geoai` (`geoai-py`), not every spatial-intelligence feature.
- Keep the capability boundary explicit:
  - A: directly provided or documented by `geoai-py`.
  - B: built with `geoai-py` plus geospatial or AI ecosystem libraries.
  - C: a product/service capability that consumes GeoAI outputs.
- Verify current APIs against the installed package, source, or official documentation. Do not label B or C work as a built-in GeoAI function.
- Treat the user as a beginner who supplies goals, sample data, and visual feedback. Explain decisions in clear Chinese and handle implementation, environment work, debugging, and verification end to end.

## Repository Conventions

- Keep one capability in `capabilities/<number>-<name>/`.
- Every capability must have a `README.md` and `requirements.txt`; add code, tests, configs, and examples only when needed.
- Share compatible dependencies through `requirements/base.txt`. Use `.venvs/<capability>` for isolated environments when needed.
- Use Python 3.12 for GeoAI and deep-learning capabilities. Do not install project dependencies into system Python.
- Store reusable code in `src/geoai_common/` only after it is genuinely shared.
- Keep raw data, processed data, weights, caches, and generated outputs out of Git and under the existing `shared/` layout.

## Capability Workflow

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.
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.
8. Update the capability README and `PROJECT_CONTEXT.md` after verified changes.

## Engineering Rules

- Prefer existing project patterns and `geoai-py` APIs over new abstractions.
- 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.
- Do not commit unless the user explicitly asks.