AGENTS.md git:20261016.c95800bA

Immutable. This exact content never changes and is served at /api/v1/blob/f79ce29a32aad121.

# MindIE Agent

This repository owns architecture, domain boundaries and product entry documentation.
Native implementations live in `mindie-agent/mindie-agent-codex`,
`mindie-agent/mindie-agent-kimi` and `mindie-agent/mindie-agent-cc`.
Shared runtime components live in their own repositories under `mindie-agent`.

Use native local tools for this repository. It has no bootstrap, workspace manager,
client hook, MCP server, Skill catalogue, dependency lock or business source checkout.
Use the user's business repository and the selected Harness plugin for actual tasks.

Follow [design principles](docs/design-principles.md) and the [architecture](docs/architecture.md).
MindIE Agent inherits all nine VAWS design principles; retiring the old runtime
does not retire or replace those principles.
Keep implementation status distinct from the target design and real acceptance evidence.
Do not add old VAWS aliases or an alternative legacy installation path.
Do not alter the user's unrelated skills, plugins or MCP configuration.

## Paired component and plugin releases

Before publishing a plugin Release, follow the
[paired-release checklist](docs/release-compatibility-and-update.md#组件与插件配套发布).
Every first-party runtime dependency in its final lock must have a published,
non-draft, non-prerelease component Release whose tag resolves to that exact
locked commit. Verify package versions and downloaded artifacts; a merge, green
CI or a fixed Git revision alone is not a component Release. Publish dependencies
before consumers, reuse unchanged releases, and keep component version histories
independent. Record the complete mapping and actual evidence in the product
release record. Content-only knowledge updates follow their publication contract.

## Mandatory design-principles review before PR submission

All MindIE Agent development tasks MUST read the current [design principles](docs/design-principles.md) and review the final diff and affected behavior against all nine principles before creating any PR, including a draft. This covers code, configuration, dependencies, CI and project documentation. Review subsequent PR changes against the affected principles again.

Errors MUST remain visible to the caller. Never turn a required-step failure into success, empty data, first use, user disablement or an undocumented fallback. Distinguish completed work, failure and uncertain external effects; do not repeat an uncertain write or hide the original error behind a later failure.

Fix principle violations before submission. In the PR description, record the reviewed commit and principles revision, concrete conclusions and applicability, findings and fixes, and actual validation or remaining gaps. Tests passing, checkboxes, blanket N/A or “all principles followed” are not a review. If the principles cannot be read or the review is incomplete, report that explicitly and do not create or update the development PR until review is complete. Pure knowledge/feedback contributions follow their content rules; development of those features remains subject to this review.