# 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.
