docs: July 2026 roadmap refresh

docs/problems/platform-nativeness.md

@@ -131,7 +131,7 @@ gh-aw's container isolation is strong for its use case, but the isolation bounda
 
 - **Should fullsend adopt gh-aw as its containment and execution layer?** Rather than building parallel infrastructure for cross-repo dispatch, credential isolation, and agent sandboxing, fullsend could use gh-aw directly for the containment layer and focus its engineering effort on the judgment layer (intent verification, review composition, merge authority). gh-aw workflows are markdown files — agents can author them, aided by gh-aw's own [documentation MCP server](https://github.github.com/gh-aw/reference/gh-aw-as-mcp-server/). The `gh aw` CLI already handles compilation, security scanning, and lock file generation. Fullsend would not need to replicate any of this.
 
-- **Is the forge abstraction worth the cost at this stage?** Fullsend's only concrete implementation is GitHub. If forge-neutrality is deferred to Phase 4 (domain specificity in the [roadmap](../roadmap.md)), the current implementation could use GitHub-native primitives directly, simplifying the stack substantially.
+- **Is the forge abstraction worth the cost at this stage?** Fullsend's only concrete implementation is GitHub. If forge-neutrality is deferred to the [Infrastructure](../roadmap.md#infrastructure) and [Cross-forge orchestration](../roadmap.md#cross-forge-orchestration) work in the [roadmap](../roadmap.md), the current implementation could use GitHub-native primitives directly, simplifying the stack substantially.
 
 - **Can gh-aw's safe-outputs model be extended for autonomous merge?** If a safe-output type of "merge this PR" were added (gated by all required checks passing and a confidence threshold), gh-aw's architecture could support tiered autonomy without fullsend's external plumbing. This depends on GitHub's willingness to add such a capability — which their current position suggests is unlikely.