Support GPT-6 Sol, GPT-6 Luna, and an exact Opus 5.5 pstack pin

[garysmall]

Problem

The personal pstack sheet can select GPT-6 Astra but the shared model matrix lacks GPT-6 Sol, GPT-6 Luna, and an exact Claude Opus 5.5 pin. The external runner rejects every versioned Claude model, so a sheet cannot guarantee that its Opus lane stays on 5.5.

Scope

• Add optional GPT-6 Sol and Luna descriptors without changing the upstream default panel.
• Support claude:claude-opus-5-5@medium for Codex external and Claude-native routes.
• Keep the Opus 5.5 external route on that model and reject mismatched provider reports.
• Update the personal sheet and its Codex AGENTS mirror only after all selected routes pass live probes.

Verification

• Bun tests, strict typecheck, static invariants, and plugin manifest validation pass.
• Native Codex probes pass at Astra high and max, Sol max, and Luna medium and xhigh.
• Claude Code 2.1.280 reports claude-opus-5-5 for the external medium probe.
• The four-lane read-only panel and an independent judge pass.

[mast-factory]

Factory Triage

Problem statement

The repository cannot represent the requested optional GPT-6 Sol/Luna choices or an exact claude:claude-opus-5-5@medium lane. The current shared matrix is intentionally fixed to four required/default families, and every numeric Fable/Opus model is intentionally normalized to a rolling alias or rejected before runner execution. As a result, adding rows naïvely would change the upstream-derived default panel, while the exact Opus 5.5 descriptor is currently rejected even though the downstream command and provider-report matcher can preserve and verify it.

Classification

• Type: feature request
• Severity: medium
• User impact: medium — users who need GPT-6 Sol/Luna or a stable Opus 5.5 lane cannot configure those routes; existing four-family defaults continue to work.
• Implementation effort: high — the matrix, setup transaction, native-agent frontier, external-runner validation, static invariants, docs, and live harness acceptance are coupled.
• Confidence: high

This is a feature request rather than a regression: the rolling-only Claude policy and four-family setup are explicit, tested behavior introduced with v1.4.1.

Evidence and root cause

• plugins/pstack/skills/poteto-mode/references/provider-dispatch.md:11-26 declares exactly Fable, GPT-5.6 Sol, Grok, and rolling Opus, then requires numeric Fable/Opus predecessors to normalize to aliases and says never to pass the versioned predecessor to Claude.
• plugins/pstack/skills/poteto-mode/scripts/runner/model-matrix.test.ts:24,109-112,205-231 hard-codes four ordered matrix rows and derives first-run defaults from every row. :234-275 also requires the exact Claude-native agent set implied by the matrix; :278-307 places all matrix defaults in each default panel role.
• plugins/pstack/skills/setup-pstack/SKILL.md:44-72 asks and probes exactly four families, allows role changes only among those four probed families, requires every matrix family to remain represented, and writes neither the personal sheet nor the Codex AGENTS.md mirror after a failed probe.
• plugins/pstack/skills/poteto-mode/scripts/runner/model-aliases.ts:9-14 identifies every numeric claude-opus-* model as a rolling Opus predecessor. run.ts:485-499 rejects that model before execution; run.test.ts:899-906 locks in the rejection behavior.
• The command layer already passes requested models through unchanged: Claude receives --model <model> and Codex receives --model <model> (commands.ts:66-120). Once narrowly admitted, reportedModelMatches accepts an exact requested model or a suffixed derivative and rejects unrelated reports (parse-output.ts:176-188); run.ts:808-840 converts a mismatch into fail-closed malformed output with no result file.
• Repository-wide search found no existing GPT-6, Astra, Luna, or claude-opus-5-5 implementation. No related open/closed issue or pull request was found, and the reporter has no merged pull requests in this repository.
• History is shallow and all relevant routing files originate in the visible v1.4.1 commit (de67e6b, September 10, 2026), so there is no later local regression commit to isolate.

Reproduction

1. Configure or directly request external Claude model claude-opus-5-5.
2. validateOptions calls versionedClaudeAlias, receives opus, and raises: Claude model claude-opus-5-5 is a version pin; normalize it to opus before invoking the runner.
3. No child process, output, or receipt is created; this is the same pre-execution behavior covered by run.test.ts:899-906.
4. Adding GPT-6 rows to the current matrix without changing its schema/test contract would either fail the exact-four-row invariant or cause those rows to be included in the default panel and required setup family set, violating the issue's no-default-change requirement.

Live reproduction and acceptance probes could not run in the triage sandbox because bun, claude, codex, and grok are unavailable on PATH. The static path and existing unit contract are conclusive for the current rejection; implementation still requires the issue's specified installed-candidate probes.

Candidate fix

1. Extend the canonical model-matrix representation to distinguish the existing required/default panel families from optional selectable model entries. Add GPT-6 Sol and Luna as optional Codex models and exact Opus 5.5 medium as an optional Claude model without changing the four current first-run defaults.
2. Preserve rolling normalization for ordinary numeric Fable/Opus predecessors, but add a narrow, explicit exact-pin policy for claude-opus-5-5 so both setup-time normalization and runner validation retain that model instead of rewriting/rejecting it.
3. Map the exact Opus descriptor to both routes: an exact-model Claude-native agent for a Claude parent and the existing external runner for a Codex parent. Keep native rolling pstack-opus-* agents unchanged.
4. Generalize setup from “all matrix rows are required families” to “default families plus selected optional entries.” Probe every selected route first; only after all pass should setup update ~/.codex/pstack-models.md and its bounded Codex AGENTS.md mirror. Preserve the current unchanged-on-any-failure transaction.
5. Update runner and parser tests for exact Opus acceptance, mismatched provider-report rejection, and Codex pinned-argv evidence. Update matrix/setup/static tests so optional entries are valid but cannot alter the default panel, and so the declared Claude-native frontier remains exact.
6. Run the repository-required Bun suites, strict TypeScript checks, static invariants, and plugin-manifest validation, then perform the issue's named Codex/Claude live probes, four-lane read-only panel, and independent judge before writing personal configuration.

Likely implementation scope

• plugins/pstack/skills/poteto-mode/references/provider-dispatch.md
• plugins/pstack/skills/setup-pstack/SKILL.md
• plugins/pstack/skills/poteto-mode/scripts/runner/model-aliases.ts
• plugins/pstack/skills/poteto-mode/scripts/runner/run.ts
• plugins/pstack/skills/poteto-mode/scripts/runner/parse-output.ts if exact-match semantics need tightening
• Runner/model-matrix/parser tests under plugins/pstack/skills/poteto-mode/scripts/runner/
• New exact-model Claude-native agent descriptor(s) under plugins/pstack/agents/
• Any static maintenance or release documentation that enumerates the four-family model surface

Assumptions and open questions

• Assumption: provider model identifiers are gpt-6-sol and gpt-6-luna; live Codex probes must confirm the exact accepted identifiers before any personal configuration write.
• Assumption: exact Opus 5.5 is an additional opt-in route, not a replacement for the rolling opus family or its five existing native agents.
• Confirmed external state: the reporter's current personal sheet and Codex AGENTS.md mirror are not repository artifacts; implementation must read/preserve them transactionally at runtime.
• Blocking product questions: none identified. The issue is sufficiently specified for planning.

Duplicate / supersession result

No duplicate or superseding issue/PR was found.

Recommended next stage

Plan fix. The request is actionable and well-scoped, but the implementation should first define the optional-vs-default matrix contract and verification sequence because those semantics span routing, setup, generated native agents, and fail-closed personal configuration writes.