git:20261016.c95800b to git:20261017.e6ad76c

- 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.