Add Protocol 27 Mainnet section to software versions

[kaankacar]

Protocol 27 (Zipper) is live on Mainnet. This adds the Protocol 27 Mainnet section to the software versions page with all component versions updated, keeping the Testnet section for history.

Fixes #11

[github-actions]

🤖 Claude docs review

NEEDS-CHANGES

Mechanics

• ✓ Heading style matches existing ## Protocol N (Mainnet/Testnet, Month Day, Year) convention
• ✓ Table structure/columns match the rest of the page
• ✓ Links are external absolute URLs (github.com, stellar.org), consistent with how other Release Notes sections link out — no internal relative-link violations introduced
• ✓ No new images

Technical accuracy

• ✗ Activation date is wrong. The heading reads ## Protocol 27 (Mainnet, July 9, 2026), but issue sd-008: The Software Versions page still presents Protocol 27 as Testnet-only after Mainnet activation #11 (sd-008) — which this PR closes — cites ledger evidence that Protocol 27 activated on July 8, 2026 (ledger 63386818 closed 2026-07-08T17:00:05Z under Protocol 26; ledger 63386819 closed 2026-07-08T17:00:10Z under Protocol 27), and its own recommendation explicitly asks for a Protocol 27 (Mainnet, July 8, 2026) section. Please confirm the correct date against Horizon/stellar-core release data and fix — a wrong activation date on this page is exactly the kind of drift issue sd-008: The Software Versions page still presents Protocol 27 as Testnet-only after Mainnet activation #11 was filed to correct.
• ✓ Smart Contract Rust SDK and Stellar CLI are correctly filled in as 27.0.0 (were TBD on the Testnet row), matching issue sd-008: The Software Versions page still presents Protocol 27 as Testnet-only after Mainnet activation #11's recommendation and the cited rs-soroban-sdk/stellar-cli v27.0.0 releases.
• ✓ CAP-71 description (Authentication Delegation and Address-Bound Soroban Credentials) matches the internal protocol-meeting notes in meeting-notes/2026-04-30.mdx.

Non-blocking nits

• Poseidon Rust SDK, Stellar Galexie, Stellar Quickstart, Stellar Horizon Client & TxnBuild, and Stellar RPC Client are still TBD on the new Mainnet row. Worth a quick check whether stable releases exist now that Mainnet has activated, same as was done for the Rust SDK/CLI rows — otherwise fine to leave if genuinely not yet released.
• Freighter cell is left blank, consistent with the pre-existing Testnet row and other historical sections, so not a regression.

Resolves: #11 (sd-008 — Software Versions page still showed Protocol 27 as Testnet-only after Mainnet activation). This PR addresses the core gap but needs the date corrected before merge.

[kaankacar]

🤖 Docs review (claude-routine variant)

Verdict: NEEDS-CHANGES

This adds the missing Protocol 27 Mainnet section requested by #11 and correctly fills in the Smart Contract Rust SDK / Stellar CLI rows (previously TBD), but introduces three factual errors on the very page #11 was filed to fix. Recommend not merging until these are corrected.

Evidence

• Activation date is off by one day. docs/networks/software-versions.mdx:19 (PR) reads ## Protocol 27 (Mainnet, July 9, 2026). Issue sd-008: The Software Versions page still presents Protocol 27 as Testnet-only after Mainnet activation #11's own cited ledger evidence — which this PR is supposed to resolve — puts activation on July 8: ledger 63386818 closed under Protocol 26 at 2026-07-08T17:00:05Z, and ledger 63386819 closed under Protocol 27 at 2026-07-08T17:00:10Z. Every other Mainnet heading on this page uses the activation date (e.g. docs/networks/software-versions.mdx:50 on main: ## Protocol 26 (Mainnet, May 6, 2026)), so this heading should read July 8, not July 9. (An earlier automated review comment on this PR flagged the same thing — confirming independently.)
• Stellar Core version contradicts the PR's own release-notes link. docs/networks/software-versions.mdx:28 (PR) lists Stellar Core | 27.1.0, but the Release Notes bullet the same PR adds at docs/networks/software-versions.mdx:50 links to stellar-core tag v27.0.0, not v27.1.0. There's no second link or citation for a 27.1.0 release, and I could not find a v27.1.0 stellar-core tag corroborating it. Either the version cell or the release link needs to be corrected so they agree.
• Stellar JS Stellar Base version regresses. docs/networks/software-versions.mdx:36 (PR) lists Stellar JS Stellar Base | v14.0.0 for this (later) Mainnet section, but the already-merged Protocol 26 Mainnet section — two protocols earlier, dated May 6, 2026 — already lists v15.0.0 (docs/networks/software-versions.mdx:67 on main). A subsequent protocol section showing an older Base version than an earlier one is very likely wrong and needs the correct current version.

Non-blocking nits

• Several cells in the new Mainnet row are still TBD: Poseidon Rust SDK, Stellar Galexie, Stellar Quickstart, Stellar Horizon Client & TxnBuild, Stellar RPC Client (PR lines 30, 34, 35, 38, 39). Worth a quick check whether stable releases now exist post-activation, the way it was done for the Rust SDK/CLI rows — fine to leave as-is if genuinely unreleased.
• Freighter cell is blank, consistent with the pre-existing Testnet row and other historical sections — not a regression.
• Table structure, heading convention, and external links otherwise match the rest of the page; no mechanical issues found.

Resolves #11? Not yet. The requested Mainnet section and SDK/CLI values are present, but the wrong activation date and the Stellar Core / Base version issues above mean merging as-is would leave (or add) the same kind of version-status drift #11 was filed to correct.

Sequencing: None — single file, no ordering dependency on other open PRs.

---

Generated by Claude Code

[github-actions]

🤖 Docs review (agentic-workflow variant)

Verdict: needs-changes — The new Mainnet section contains several TBD/empty version entries and a likely version regression; a Mainnet section should have complete, final version data.

---

Evidence

Incomplete version entries (Mainnet section should not have TBDs):

• docs/networks/software-versions.mdx (new lines ~22–38): Poseidon Rust SDK, Stellar Galexie, Stellar Quickstart, Stellar Horizon Client & TxnBuild, and Stellar RPC Client are all marked TBD.
• Freighter version cell is blank (same issue as the Testnet row on main, but for a live Mainnet entry this is more notable).

Possible version regression:

• docs/networks/software-versions.mdx new line ~35: Stellar JS Stellar Base is listed as v14.0.0. The Protocol 26 Mainnet section on main shows v15.0.0. A major-version downgrade across a protocol bump looks wrong — please verify; the correct value may be v15.1.0 or similar.

Checks:

• build / build was still in progress at review time; mdx-format passed. mergeable_state is unstable — confirm CI is green before merge.

---

Nits (non-blocking)

• The section header uses "July 9, 2026" as the activation date — worth double-checking against the official announcement.
• The Stellar Core version jumps from 27.0.0 (Testnet) to 27.1.0 (Mainnet); this is plausible (patch release for mainnet) but worth a quick citation in the PR description for traceability.
• The Testnet row on main already lists Stellar Core as 27.0.0; the PR correctly leaves the Testnet section unchanged. No ordering or sidebar collision detected.

---

Sequencing

No other open PRs appear to conflict with this file. #11 (which this claims to fix) should be verified closed once the TBD gaps are filled.

Requested changes before merge:

1. Fill in all TBD version entries with confirmed release tags, or document why they are genuinely unreleased.
2. Verify and correct Stellar JS Stellar Base version (v14.0.0 vs expected v15.x).
3. Confirm CI (build / build) passes.

Generated by Docs PR review agent for #22 · 20.3 AIC · ⌖ 5.52 AIC · ⊞ 4.8K · ◷

[kaankacar]

📋 Reviewer comparison — how each automated review above was produced

Orchestrator note (posted from Kaan's session). This PR is a graded test: it looks like the correct fix for #11 but carries two seeded flaws — the activation date is wrong (July 9; actual: July 8, 2026, ledger 63386819) and the description claims "all component versions updated" while five rows remain TBD. Three review architectures ran against it independently.

---

1 · 🤖 Claude docs review — GitHub Actions + claude-code-action

What it is: four plain Actions workflows living in .github/workflows/; on PR events, Claude Code (claude-sonnet-5) runs inside the runner with a pinned allowlist of read-only gh commands, verifies claims against the checkout, and posts one signed comment.
What it did here: NEEDS-CHANGES — caught the wrong date as the blocking issue by cross-referencing #11's ledger evidence; flagged the TBD rows as nits; verified the CAP-71 wording against the repo's meeting notes.
If given full action rights: per the triage policy it applies labels and, in the issue lane, may auto-close only refuted agent-findings and exact duplicates. It never merges — the highest-confidence trivial PRs get an auto-merge-candidate label and a human merges. Granting gh pr merge is technically one allowlist line; withheld deliberately (the gate is policy, not capability).

2 · 🤖 Docs review (agentic-workflow variant) — GitHub Agentic Workflows (gh-aw, public preview)

What it is: a natural-language markdown workflow compiled by gh aw compile into a locked pipeline. The reviewing agent (Copilot engine) runs read-only; anything it wants to write is emitted as structured "safe outputs" that a separate permission-gated job validates (label allowlist, max one comment, threat scan) and applies.
What it did here: needs-changes — led with the TBD gaps and caught the JS Stellar Base v14.0.0 regression vs the P26 section; noted CI was still running; date raised only as a nit.
If given full action rights: its ceiling is structural — close-issue and merge-pull-request are simply absent from its safe-outputs config, so even a fully prompt-injected agent cannot close or merge; the maximum possible action is one comment plus three allowlisted labels. Raising the ceiling is an explicit config change reviewed like any code.

3 · 🤖 Docs review (claude-routine variant) — scheduled Claude cloud agent (posted by @kaankacar)

What it is: a "routine" running in Anthropic's cloud (not in this repo, not on a laptop) on a cron or one-shot schedule, with its own clone of the repo. Nothing is installed in the repository — note this comment's author: the routine acts as the account that owns it, so its review reads as if the owner wrote it.
What it did here: NEEDS-CHANGES — caught both seeded flaws and two unseeded real errors (the Stellar Core 27.1.0 cell contradicting the PR's own v27.0.0 release-notes link, and the JS Base regression), crediting the earlier bot review as independent confirmation of the date issue.
If given full action rights: anything the owning account can do — label, close, even merge, as that user. That is precisely why this demo scoped it to exactly one comment, and why this architecture fits a personal review assistant better than an org bot (options 1/2 comment under bot identities; this one doesn't).

---

Scorecard on the graded test

Finding	1 · claude-code-action	2 · gh-aw/Copilot	3 · routine
Seeded: wrong activation date (Jul 9→8)	✅ blocking, with ledger evidence	⚠️ nit only	✅ blocking, with evidence
Seeded: "all versions updated" vs 5 TBD rows	✅ nit	✅ blocking (led with it)	✅ blocking
Unseeded: JS Base v14 regression vs P26's v15	—	✅	✅
Unseeded: Core 27.1.0 vs the PR's own v27.0.0 link	—	⚠️ asked for citation	✅ contradiction called out
Extras	CAP-71 wording vs meeting notes	CI/merge-state check	deepest cross-referencing

None of the three has merge or close authority on this PR — by policy (1), by construction (2), and by prompt scope (3).

[kaankacar]

🤖 Docs review (claude-code-action + Raven, local run)

This is the Raven-assisted variant of the reviewer, run locally (the Stellar Raven MCP is browser-OAuth only and can't yet run in CI — see note at the end). Its distinguishing move: verify ecosystem-context claims against dated primary sources instead of trusting the PR text or the issue body.

Verdict: NEEDS-CHANGES

Raven-verified (the reason this variant exists)

• ✗ Activation date is wrong — confirmed against a dated SDF source, not just issue sd-008: The Software Versions page still presents Protocol 27 as Testnet-only after Mainnet activation #11. The heading docs/networks/software-versions.mdx:19 reads ## Protocol 27 (Mainnet, July 9, 2026). Raven (lumenloop.search_content_semantic) returns SDF's own "Stellar Zipper, Protocol 27 Upgrade Guide" (stellar.org, published 2026-06-04), which states Protocol 27 launches July 8. Every other Mainnet heading on this page uses the activation date, so this should read July 8, 2026. This is exactly the drift sd-008: The Software Versions page still presents Protocol 27 as Testnet-only after Mainnet activation #11 was filed to fix — reintroducing a wrong date defeats the PR's purpose.
• CAP-0071 (Authentication Delegation) is corroborated as the P27 headline feature by the same dated guide, consistent with the release-notes bullet the PR adds.

Verified against the repo (path:line)

• ✗ "All component versions updated" (PR description) vs. reality: five rows in the new Mainnet table are still TBD — Poseidon Rust SDK, Stellar Galexie, Stellar Quickstart, Stellar Horizon Client & TxnBuild, Stellar RPC Client (docs/networks/software-versions.mdx:30,34,35,38,39 in the PR). A Mainnet section shouldn't ship with TBDs presented as complete.
• ✗ Stellar JS Stellar Base regresses: the new section lists v14.0.0 (PR :36), but the already-merged Protocol 26 Mainnet section — an earlier protocol — lists v15.0.0 on main. A later section can't have an older major version; please confirm the current tag.
• ⚠️ Stellar Core 27.1.0 (PR :28) isn't backed by the PR's own citation: the Release Notes link the PR adds points to stellar-core tag v27.0.0, not v27.1.0. Raven shows stellar/stellar-core active (last commit 2026-07-11) but I could not confirm a v27.1.0 tag from here — either fix the cell or cite the 27.1.0 release so they agree.

Non-blocking nits

• Freighter cell left blank — consistent with prior sections, not a regression.

Resolves: #11 — addresses the core gap (adds the missing Mainnet section) but must correct the date + version issues before merge.

---

Raven note: this comment was produced by a local run because the Raven MCP authenticates via browser OAuth and has no CI-usable service token today. In GitHub Actions (options 1/2) this lane is skipped and the reviewer falls back to repo + gh evidence. A service token from the Raven operator would make this lane CI-native.