📝 docs: refine vision, SEP process, and signature surface

[zrr1999]

Proposal summary

This PR realigns the Spore documentation stack from vision to SEP process to the root language surface.

• Reframes VISION.md as principle-level language vision only, centered on the Signature -> Property -> Hole -> Realization -> Evidence pipeline, and adds a synchronized Simplified Chinese vision document.
• Moves process mechanics and design-review prompts into seps/SEP-0000-process.md, including the Pitch -> Draft -> Accepted / Rejected lifecycle, review inside Draft status, canonical guiding questions, and merge-check expectations.
• Materially revises the already Accepted SEP-0000: SEP now means Spore Evolution Proposal, SEP-0000 becomes the stronger owner of governance/process mechanics, and bootstrap amendment rules make direct accepted-SEP edits explicit rather than silent.
• Moves SEP-0001 back to Draft while revising the signature/root surface grammar: Base Signature + Intent Signature clauses, fixed clause order (uses, budget, properties, body), a compact root item grammar, and explicit delegation of type/effect/budget/hole/concurrency/module/std semantics to later SEPs.
• Aligns SEP-0002 through SEP-0009, seps-index.json, templates, PR checks, dependency metadata, and validation paths with the updated SEP layering and terminology.
• Unifies the public uses [...] terminology around effects: uses is now the effect surface, HoleReport exposes effect_context, and the previous capability/checker-capability wording is removed from core docs.
• Updates README.md, GLOSSARY.md, terminology checks, and style terms; removes the stale root ROADMAP.md in favor of the SEP-centered reading path.

Linked discussion

SEP front matter links the existing public discussion threads for the affected documents:

• SEP-0000 process discussion: SEP-0000 Review: Spore Enhancement Proposal Process #41
• SEP-0001 syntax discussion: SEP-0001: Core Syntax & Signatures #1

Canonical review for this combined amendment remains this PR. Because this directly amends already Accepted SEP-0000 and moves SEP-0001 back to Draft, the review focus below explicitly asks whether any part should instead become a follow-up Process or Standards Track SEP.

Checklist

• I opened or linked a public Discussion or Issue for the pitch before submitting this draft SEP.
• I linked the canonical discussion thread.
• I used the correct SEP template for this proposal type.
• I updated front matter metadata and required sections.
• I considered the SEP-0000 guiding questions in the relevant proposal sections.

Notes for reviewers

Review focus

Please review this as a documentation/process change with unusually high impact because it edits Accepted SEPs:

1. Accepted SEP governance: Are the changes to SEP-0000 appropriate as a direct update, or should some of this be split into a follow-up Process SEP?
2. Draft language surface: Is the SEP-0001 rewrite acceptable as the draft root surface grammar, or should it be treated as a replacement Standards Track proposal instead?
3. Responsibility boundaries: Does VISION.md stay principle-level while SEP-0000 owns guiding questions and process mechanics?
4. Signature scope: Does SEP-0001 correctly specify only the root surface and delegate deeper semantics to SEP-0002 through SEP-0009?
5. Effect terminology: Is the capability -> effect terminology consolidation correct, including effect_context, EffectContext, and F0xxx effect diagnostics?
6. Bilingual terminology: Are the Chinese vision and core glossary mappings correct, especially Spore -> 孢子 and Agent -> 智能体?

Risks / open questions

• SEP-0000 remains Accepted under a one-time direct amendment exception; SEP-0001 returns to Draft because this PR changes it substantially. Reviewers should decide whether that is acceptable in one PR or whether a separate process/standards amendment is required.
• Removing ROADMAP.md may affect external links; the intended replacement is the README/vision/SEP-index reading path.
• The signature grammar is intentionally a root-surface contract. Follow-up SEPs still need to preserve the delegation boundaries introduced here.
• Non-effect checker or Agent guidance is now explicitly out of uses [...]; if needed, it should receive a separate future tooling surface instead of reusing effect terminology.

Validation

• prek run: passed
• prek run --all-files: passed
• git diff --check: passed
• zendev title validation: passed
• zendev body validation: passed
• commit hook suite via git commit: passed
• GitHub PR checks after latest push: passed (PR title, PR body, prek, repo-checks)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1497fde779

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".