| English | 中文 |
See the project layout: human methods, computer-operation skills, declarations and shared execution have separate responsibilities. Scientific design explains research choices; workflow recipes describe reusable combinations; skills own executable operations.
Choose an actual capability, check inputs, permissions and data contracts, then deliver verified results with sanitized records. General rules do not prescribe a named model, framework or technology category. Concrete capabilities belong in skill navigation and classified usage.
Use the four-step workflow and methods. Methods-only stages do not provide implementation; reference entries do not imply executability. Documentation work does not read original data.
| Need | Guide |
|---|---|
| Organize experiments around a scientific question | Numbered research projects |
| Install, inspect catalogs and local files | Core tools |
| Separate data, configuration and authentication | Storage |
| Shared data, project results and human review | Assets |
| Acquire/prepare data | Classified acquisition |
| Check provenance, uncertainty and normalization | Data quality |
| Analyze existing results or adapt templates | Classified analysis |
| Find reusable specialist workflows | Skills, methods |
| Modify the project safely | Agent boundaries, AGENTS.md |
| Add a capability | Authoring, registration |
| Inspect readiness or execute an adapter | Queries, run-tool |
| Improve a capability from selected task evidence | Improvement contract, maintenance operations |
| Review evidence and unperformed checks | Verification |
Keep personal task records outside Git. Shared rules describe collaboration; skills describe concrete domain workflows.
| Layer | Responsibility |
|---|---|
| Skill | Task suitability, steps, inputs/outputs and limits |
| Tool | One explicit action using an implemented entry or a clearly labeled template |
| Dataset catalog | Source, owning skill and cache metadata, not acquisition |
| Workflow | Handoffs and assumptions; design is not orchestration |
| Runtime harness | Preflight, reviewed calls, states and receipts; supported adapters only |
| Evaluation | Interface checks, artifact checks and separate scientific validation |
Task authorization → discover capability → check inputs/dependencies/write scope → execute implemented entry → validate artifacts/method → retain local evidence → share sanitized results.
Users define scope and intended use. Domain contributors explain methods, units, assumptions and acceptance criteria. Platform maintainers keep interfaces, metadata and environments compatible. Reviewers check a minimal reproducible case, scientific scope and the actual diff.
Roles may overlap, but a scientific calculation change should receive independent domain review. Roles, repository permissions and task authorization are separate. Use individual accounts, checkouts, environments and task directories; shared input roots remain read-only and caches/outputs must not be concurrently overwritten.
Continue authorized reversible work without repeated confirmation. Missing authorization or necessary information requires clarification; documentation does not authorize installation, downloads or costly work.
A task brief should specify the repository entry, bounded question, allowed inputs and operations, expected evidence, missing-data behavior and sanitized reporting. Do not silently replace missing inputs with zeros, change years/resolution or expand scope.
Keep reusable code, documentation, schemas and declared synthetic assets and explicitly authorized licensed public data snapshots in Git. External AIRMOSAIC_ASSETS_DIR stores shared data by stage/name/version and project results, with task-selected internal layouts where supported. Generic demonstrations may use reviewed, Git-ignored skill results. Personal settings and authentication remain separate; see the asset contract.
Explicitly override legacy output defaults for new tasks without moving old files. External releases remain separately configured read-only inputs; configuration edits use task copies. Use logical roots and IDs in shared documents. Variable strings are not automatically expanded unless the caller implements it.
Read-only discovery and readiness checks do not execute actions or validate scientific content. Inspect real manifests and use the runner for supported adapters. Review can_execute/blockers in dry-run, then actual state and artifacts.
Implemented preflight, minimal environments and sanitized receipts apply only to reviewed adapters, not direct scripts. The runner is not an OS sandbox. Authentication, dependency loading, live integration and scientific acceptance are distinct. Local stdio MCP is available through the connection guide. Workflow orchestration and remote service interfaces remain proposals.
Record source/configuration versions, scope, parameters, inputs, outputs and validation status locally. Preserve complete diagnostics only in authorized locations without secrets. Share logical IDs, relative paths, counts, units and sanitized errors. Distinguish source review, synthetic checks, real integration and scientific validation. An existing file or successful process is not enough.
Handoffs specify unique keys, units, time/space support, missingness, mappings, uncertainty and acceptance evidence. Do not automatically chain modules or publish a cache merely because an upstream task succeeded.
Define a bounded change, inspect existing work, use a task branch/check-out when appropriate, maintain both documentation languages, and follow authoring and registration. Run relevant checks and privacy review before an authorized commit, push or release.
Separate approved prerequisites and unrelated work. Do not force-push, rewrite history, start later roadmap tasks or change repository permissions merely because a role or plan mentions them. Future distribution/interfaces require implementation and task-specific validation before being described as operational.