Make docs onboarding and the Summer SDK lifecycle Summer-first

[mathias-heide]

What changed

• Reorganizes the public docs into Start here → Summer SDK → Test and publish → Automation → Reference → Migration and extensions.
• Makes the creator identity explicit: developers install Summer Engine, build a Summer game in GDScript, and add platform contracts through the Summer SDK.
• Removes Godot-led product metadata from the root journey, What is Summer, VS Code, 2D, SDK, agent, migration, and existing-project pages.
• Rewrites compatibility pages so upstream lineage is a technical fact, not product identity. The pinned current upstream base is 4.6.1, the planned next base is 4.7.1, and Summer follows upstream continuously.
• Fixes the canonical fenced project.godot example from config/features=PackedStringArray("4.5") to "4.6".
• Makes local validation honest: the canonical agent prompt runs a one-process Summer Engine import/smoke pass with local SDK stubs; an optional starter runner is local loopback only and does not prove platform or ticket flows.
• Adds one canonical Live / Scaffold / Planned platform status table at /knowledge-base/source-status.
• Adds explicit canonical rows and required policy entries for the Planned production gameplay runtime and Scaffold hosted persistence/economy path.
• Removes claims that uploaded games can already be played or that hosted matchmaking, dedicated servers, deployment, and the production runtime sandbox are live.
• Adds a 129-public-route capability guard and strengthens the product-language guard to inspect navigation routes, frontmatter, prose, and fenced project/config examples.
• Moves the default Docs journey to Start here → Summer SDK → Test and publish, with legacy/alternate entry points below the canonical path.
• Qualifies broad export, existing-project compatibility, no-code complete-game, fixed model-integration schedule, and “safe operations” claims; creators remain responsible for installed target tooling, review, testing, and integration.
• Replaces brittle exact-phrase checks with a schema-v2 capability policy: per-capability subject aliases, assertion verbs/terms, status terms, and disclaimer patterns.
• Parses creator-facing prose and fenced prompts/configuration into sentences and contrast clauses. Status/disclaimer clauses cannot suppress a later positive clause, while true local negations such as “never writes,” “never executes,” and “cannot power” remain valid.
• Carries capability subjects across sentence boundaries only through genuine anaphors such as “It” and “They”; unrelated explicit subjects break carry. Local/private/test and modal/hypothetical assertions are scoped to their own claim and cannot hide a later production assertion.
• Carries omitted subjects across contrast clauses only when the new clause begins with a compatible capability predicate. Capability-specific predicate/object checks reject production ellipses while allowing unrelated live documentation and concise-reference statements.
• Rejects all prior and follow-up reviewer mutations, including fresh web-client playback, automatic lobby pairing, cloud game provisioning, production uploaded-pack isolation, live multiplayer replication, Summercraft execution, durable inter-session storage, and Planned, yet operational contradictions.
• Requires every public route that names scaffolded SDK surfaces to link to the canonical status, with one owned changelog exception.
• Marks singleton, player identity/input, runtime enforcement, persistence/economy, backend flush, team/score, and multiplayer examples as Scaffold or future contract behavior.
• Removes blanket project/plugin/tutorial compatibility claims and requires committed-copy, import, native-extension, plugin, and export verification.
• Separates the recommended 1 KiB–512 MiB release API path from the browser .pck + manifest.json path with its 2 GB limit and static scanner.
• Preserves narrow upstream terminology for compatibility, migration, extensions, upstream API research, attribution/legal contexts, literal file names, and verified third-party porting requirements.

Pinned compatibility contract

• Engine commit: b44e47792819fb402a2984cd79c7023cc8aa57f8
• Current upstream technical base: 4.6.1
• Planned next upstream technical base: 4.7.1
• Policy: continuous-upstream
• Product identity: Summer Engine releases remain separate from upstream numbering

Validation at exact head

Exact head: 5d1256154775dadcbd50d973a7e50f888b160030

• npm run check — PASS
  • compatibility sync pinned to the engine contract — PASS
  • language guard — PASS across all 129 public navigation routes
  • capability guard — PASS across all 129 routes, one canonical status source, seven semantic capability policies, route-aware scaffold disclosures
  • mutation fixtures — PASS: eleven language rejects/three allows, nine compatibility rejects/four allows, thirty-eight capability rejects/twenty-four allows
  • route snapshot — PASS, 129 unique routes and 33 redirects
  • docs policy — PASS, 0 errors; three unchanged pre-existing orphan warnings
• DOCS_CHECK_BASE=origin/main node scripts/check-docs.mjs — PASS, 0 errors; same three pre-existing orphan warnings
• npm run check:external-links — PASS, 7 unique external URLs across 12 canonical changed routes
• node scripts/check-external-links.mjs --all — PASS, 51 unique URLs across all 132 pages; one expected access-controlled 403 warning for https://itch.io/game/new
• mint validate — PASS
• mint broken-links — PASS
• Project/config fence audit — only two config/features examples remain, both "4.6"
• Public title/description audit — the only remaining Godot term is the technically necessary godot-cpp branch gap on the GDExtension compatibility route

Visual QA

Before this remediation follow-up, root visual QA passed desktop and 390×844 mobile rendering for the root, installation, SDK, update, and compatibility routes, including mobile navigation and the product switcher. This follow-up changes copy on several of those routes and adds no layout primitive. No new visual inspection is claimed for the newly rewritten migration, source-status, multiplayer, or extension pages.

Necessary upstream references that remain

Godot Engine is named only where the upstream fact is needed: existing-project migration, pinned compatibility, GDExtension/plugin/module compatibility, upstream API research, attribution/legal context, literal project.godot paths, and actual third-party porting requirements. Creator-facing product copy remains Summer-first.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.