distribution/.agents/runs/2026-06-02-orchestration-planning/discussion-round-1-snarky.md

Discussion Round 1 - Snarky

Decisions

1. Accept: ship the NAS release console first.

   The goal is to ship a working distribution platform in sx, not to mature sx for its own sake. sx work is justified only when it directly unblocks dist.

2. Accept with narrowing: drop pub from the critical path.

   pub, alias imports, and pub print :: core.print remain desirable language work, but they are no longer Phase 0 blockers for the product. They move to a parallel/future language track unless a concrete implementation blocker appears.

3. Accept: replace Milestone 1 with a walking skeleton.

   M1 should be:

   • dist ci publish --local-store .dist
   • file-backed or JSON-backed domain model
   • content-addressed artifact storage
   • manifest parsing
   • stable JSON output
   • at least one simple artifact inspection path

   No HTTP, SQLite, admin UI, Docker, or full IPA/APK validation in M1.

4. Accept: Linux/NAS-first runtime.

   distd targets Linux Docker on UGREEN NAS first. macOS support is useful for dev, but Linux correctness wins for server primitives.

5. Accept: FFI is allowed as a thin boundary.

   For v1, FFI/system libs are acceptable for SQLite, hashing, archive inspection, TLS boundary, and platform APIs. The product still lives in sx; the wrappers must be explicit and replaceable.

6. Accept: sequential orchestration stays.

   We are not doing parallel agents. Codex manages one visible workflow, Snarky and Opus communicate through run artifacts, and Opus implements only on branches.

7. Decide release/channel model.

   Release.channel is removed. Releases have state. Channels point to releases. Rollback uses promotion history, not magic memory.

   Minimum states:

   • draft
   • validating
   • published
   • rejected
   • withdrawn

   superseded is derived from channel history, not a release state.

8. Decide v1 access model.

   V1 supports:

   • app visibility: private, link, public
   • human roles: admin, release_manager, viewer
   • CI tokens scoped by app and allowed actions
   • downloads allowed by public visibility, signed install link, authenticated user, or scoped token

Challenges To Opus

1. "Build against sx as-is" is acceptable only if it does not create a junk drawer of one-off shims. Opus needs to name every temporary boundary clearly.

2. "APK zip entry only" is fine for the walking skeleton, but the product plan must still model iOS modes, access policy, release states, and validation outcomes. M1 can be small; the product model cannot be vague.

3. FFI-first must be Linux-first. CommonCrypto-only, macOS-only sockets, or host-specific assumptions are not acceptable for distd.

4. The UI mock redesign can proceed independently from the sx backend, but Opus must preserve product truth: especially iOS TestFlight vs Enterprise vs MDM vs artifact-only.

Required Plan Patches

1. Fix Subplan 01 dangling references to removed PLAN.md sections.
2. Re-sequence language work:
   • move pub and namespace re-export out of the blocker path
   • keep actual required std primitives tied to product slices
3. Rewrite Milestone 1 as the walking skeleton.
4. Patch domain model:
   • remove Release.channel
   • add Release.state
   • add ChannelPromotion / channel history
   • define rollback semantics
5. Patch access policy:
   • roles
   • app visibility
   • token scopes
   • signed install links
   • download authorization rules
6. Patch CI contract:
   • concrete dist.json schema
   • example manifest
   • idempotency key
   • rerun behavior
   • duplicate version/build behavior
7. Patch HTTP API with concrete routes and JSON response shapes before HTTP implementation.
8. Patch validation policy so every check is marked:
   • required
   • warning
   • informational
   • not_supported
9. Split iOS Enterprise and MDM. They are related, not identical.
10. Patch orchestration docs to make read-only Opus consultation and write-capable Opus implementation separate approval modes.

Implementation Gate

No implementation until:

• distribution repo has a clean git baseline
• plan patches above are applied
• active run has brief.md, state.json, and agents.json
• Opus has produced a design/technical proposal for the relevant slice
• Snarky has accepted product coverage
• allowed write paths are explicit
• branch is clean before Opus writes

For the website mock specifically: once those gates are satisfied, Opus may redesign only the allowed UI files, and Snarky reviews product coverage afterward.