docs: streamline solo design workflow

[yanpgwang]

Problem, rationale, and scope

Mango is currently developed primarily by one maintainer. Requiring a GitHub Issue before every substantial change duplicates context that is immediately repeated in a short-lived pull request. The workflow should preserve explicit rationale and scope without making Issues an implementation gate.

Acceptance criteria:

• Issues are optional coordination and roadmap tools.
• A pull request or design document can directly carry the problem, acceptance criteria, and non-goals.
• Design starts from current Mango code/contracts/tests and compares the relevant current CMA workflow.
• Similar user problems should reuse sound established designs without requiring exact field parity.
• New Mango-specific protocol concepts require a concrete need; standard HTTP, common data shapes, and existing Mango primitives are preferred.
• Conflicting guidance outside AGENTS.md is updated.

Non-goals:

• removing focused scope, durability analysis, provenance, or test requirements
• making CMA parity a product goal
• establishing API compatibility with CMA or a third-party SDK

What changed

• replaced mandatory Issue language across repository policy and product docs
• documented direct-PR workflow for solo and short-lived changes
• clarified adopt/adapt/reject comparison against current CMA design
• added general-contract guidance against needless proprietary headers, fields, wrappers, states, and abstractions
• updated the PR template to carry problem, acceptance criteria, non-goals, and design provenance

Verification

• make docs-check
• git diff --check
• repository-wide search for obsolete mandatory-Issue wording

API impact and design provenance

No HTTP API or runtime behavior changes. This clarifies how external designs are evaluated: reuse the same sound high-level design when lifecycle semantics match, adapt or omit fields for Mango's self-hosted needs, and do not pursue field-for-field compatibility.

Durability and security

No persistence, workflow, retry, credential, tool, or sandbox behavior changes.

Checklist

• The problem, acceptance criteria, and non-goals are recorded here.
• Tests cover the changed behavior where applicable.
• Public behavior is documented.
• Material external design influences and Mango-owned decisions are recorded.
• No credentials, generated build output, or local databases are included.