| English | 中文 |
Applies to reading, editing, execution, documentation and sharing. Authorization must identify objects, inputs, writes and external actions; these rules grant no additional authority.
AGENTS.md and relevant SKILL.md; inspect branch, uncommitted work and real entries.| Material | Local use | Shared artifacts |
|---|---|---|
| Usernames, credentials, keys, tokens and cookies | Secret manager and authorized internal tool use | Never publish, including encoded, truncated or hashed substitutes |
| Home directories, drives and private server paths | Explicit local variables/configuration | Logical roots, IDs and repository-relative paths |
| Email, identities, accounts and internal endpoints | Only when needed and authorized | Roles/placeholders, except specifically authorized disclosure |
| Signed/private links and authentication headers | Authorized local calls only | Public entry and parameter categories |
| Browser profiles and sessions | Member-owned local environment | Do not copy to Git, other members or shared attachments |
| Original data, releases and business outputs | Authorized workspace/read-only roots | Metadata, methods, synthetic cases, approved summaries and explicitly publication-authorized licensed public dataset snapshots |
Public source URLs, paper identifiers and repository addresses may be cited. Report suspected credentials only by file, line and category, never values.
Logs/screenshots can expose prompts, stacks, filenames, tables, account areas and URL queries. Replacing only a home directory is not sufficient sanitization.
If a secret entered history, stop propagation and notify the maintainer for provider-side revocation/rotation. Removing the current text does not erase historical exposure. History rewriting, remote deletion and rotation need specific authorization.
Follow the storage contract. Read only needed non-secret configuration; never traverse configuration/authentication to find login details, export cookies, print full environments or package sessions. Authentication and downloads have separate scope; filesystem access does not authorize secret inspection.
A user-prepared client secret file may be internally reused only by its explicitly authorized trusted client/task. The agent must not open, parse, print, copy or hash its contents, or publish its path/fingerprint. Documentation/tests use temporary substitutes, not real secret reads or authenticated-client initialization just to confirm preparation. User-reported preparation is not verified authentication.
| Action | Rule |
|---|---|
| Relevant code/public documentation and checks without external effects | Continue within scope without repeated confirmation |
| Requested edits and new local artifacts | Preserve originals/others’ work, use task outputs and record changes |
| Installation, acquisition, paid calls or costly computation | Check existing authorization, target and resource limits |
| Login/account changes | Use the member’s session and source flow; do not collect passwords or copy sessions |
| Deletion/overwrite, shared-resource changes or job cancellation | Require target-specific authority and check recoverability |
| Push, merge, publish, upload or send messages | Verify current-task authorization after preparing reviewable sanitized content |
Existing authorization covers necessary follow-up steps. Tool discovery is not permission for bulk acquisition or all analyses.
Write general guidance in terms of task responsibilities, capability state and boundaries, without enumerating models, frameworks or technology categories. Concrete names, dependencies and invocations belong in skills and classified guides.
Routine method/engineering maintenance uses descriptions, interfaces and synthetic inputs; original-data access requires a bounded task. Methods-only stages contain no concrete data, values, code, project scripts or source fingerprints.
Document existence does not verify years, quality or permission. Catalog metadata is not acquisition; file presence is not content, checksum or scientific acceptance. Scripts are not installed tools and JSON examples are not implemented APIs.
Process success does not prove completeness. Report skipped, failed/missing and passed checks separately. Distinguish scenario differences, associations, modeled results and identified causal effects. Synthetic validation is not a successful real-data pipeline.
Pattern scans supplement review; they do not prove all secrets absent. Do not propagate a discovered secret into tests, error examples or repair notes.
Experimental results belong to their project, which retains code, settings, evaluation and review records. Only a human scientific decision can admit selected outputs to assets/; internal asset organization is deferred. Current runners retain their existing external output contracts until project-directory support is implemented. Generic demonstration exceptions remain adapter-specific. Do not move historical outputs, bypass checks or infer approval from file presence. Configuration, authentication and credentials remain separate. See the result and review contract.
Agent objectives/actions/observations, stop conditions and generation/event/retrospective records follow the common execution and process-record contract. Each adapter must declare actual capture coverage; retrospective summaries do not replace observed events.