Made of little things.

# Napcraft publication retry — visible friends and click building

## Outcome

The game changes are implemented and verified locally. **No frontend release was
published and no backend release was activated.** Two fresh attempts on soyLI
0.23.1 reproduced the existing source-publication dependency failure.

- Tested source commit: `67f8ad4a4f86331039302526473d5d15c854c623`.
- Built HTML SHA-256:
  `fc5c1e0ac629450bd5c0f4ed7357c36f6d0e31361f27c6985cec5f23984597d4`.
- Platform: darwin-arm64. `soyli doctor --json` reports current 0.23.1, Git ready,
  browser ready. No missing tool installation explains this failure.
- The selected creator, identifier, provider, destinations and Git ancestry were
  preserved. No scanner bypass, generated-file exemption or history rewrite.

See [feature and verification evidence](friends-and-building.md): 21 automated
tests, 46 hosted scenario assertions, exact mobile/desktop sizes, final media
review, backend compilation and sandbox checks passed. Conformance reported
5 passes and 5 explicit skips. Passing these checks does not establish a deployed
backend or publicly playable multiplayer game.

## Attempt 1: frontend/source publication

`soyli publish --dry-run` returned `status: dry_run` and selected the expected
source commit, build, cover, clip and napplet.soy destinations. Actual
`soyli publish` rebuilt successfully, passed sandbox checking, then exited 1:

```text
Publishing: sandbox
Publishing: freeze
SOURCE_SECRET: The source selection contains a private or generated file.
Remove it from publish.files.
Operation: soyli publish
```

`soyli status --json` subsequently returned `{"status":"not_started"}`.
No release URL exists from this attempt.

The current Git tree contains no tracked `.napplet-space` files. However,
`git rev-list --objects HEAD` still finds the historical public metadata blob:

```text
da5a170b5817cd421609301436adc0acb94235c2 .napplet-space/soy-backend.json
```

It was added in `871d25a` under the old guidance and removed in `368abc2`. The
earlier [history-validation investigation](soyli-history-publish-blocker.md)
identified the freeze validator's scan of every reachable Git blob. This attempt
reproduces that condition. Changing the current `publish.files` cannot remove an
ancestor's blob. The misleading error and dry-run gap are tooling issues, not
an invalid game handler or a credential leak discovered in the current source.

## Attempt 2: public backend deployment

Read-only provider status succeeded. The configured provider advertises
`soy.backends.v1`, `soy-ts-quickjs-v1`, Linux bwrap isolation, allowlist admission
and polling updates (minimum 2,000 ms). `soyli backend describe worlds --json`
returned `active: null`, `revision: 0`, `disabled: false`.

The backend's six operations compile locally. A fresh
`soyli backend deploy backend/backend.json` nevertheless exited 1:

```text
RUNTIME_FAILED: BackendError: Git source response refused (HTTP 404);
expected bounded smart HTTP. Redirects are not followed.
Operation: build backend release
Next: Publish/push the selected account’s committed source first, fix the
reported compiler/source cause and retry. The active release was not changed.
```

Target: the selected creator's repository at
`https://git.napplet.soy/npub182jczunncwe0jn6frpqwq3e0qjws7yqqnc3auccqv9nte2dnd63scjm4rf/n-52f9e22f5ce.git`.

This failure occurs while fetching the committed source, before compilation or
activation. It follows from the repository not being created by the blocked first
publication. It is **not evidence of a handler compile failure, incorrect world
rules, or rejected creator admission**. Admission is still a public deployment
requirement that must be verified once source fetching can complete.

The provider status/describe commands also emitted transient relay `Publish
failed; will retry` logs despite returning successful structured results and
exit 0. These did not cause either blocking error. Distinguishing recoverable
transport diagnostics from final command failures would make agent reports clearer.

## Tooling fixes and recovery order

1. Include history validation in publish dry-run/check and return the exact
   rejected path plus object/commit. The current advice to edit `publish.files`
   does not apply to a history-only file.
2. Provide an explicit, backed-up migration for historical public backend context
   created under the old bootstrap guidance. A narrow format-aware migration or
   an author-approved history cleanup can address this; do not broadly exempt
   `.napplet-space` or silently rewrite repository history.
3. After that migration, run ordinary `soyli publish` to publish committed source
   and the current build/media. `--resume` is inappropriate while status is
   `not_started` and could select old frozen bytes in other states.
4. Run `soyli backend deploy backend/backend.json`, verify the signed receipt and
   `soyli backend describe worlds` active release. Distinguish source fetch,
   creator admission, compilation and activation failures in tooling diagnostics.
5. Test two independent public players creating, joining and editing a world,
   leaving/rejoining, and recovering from connection loss. Local preview worlds
   and local TURN verification are not public hosting evidence.

Useful regression fixture: bootstrap a project that historically tracked the old
public context, remove it from HEAD, upgrade its guidance, pass local checks, then
attempt publication/deployment. Dry-run should expose the blocker early with an
actionable supported migration, and the dependent backend error should identify
the missing source-publication prerequisite.

Raw command logs are retained privately in `.napplet-space/friends-publish.log`
and `.napplet-space/friends-backend-deploy.log`. The workspace remains committed,
the final cover/clip are selected, and the preview session has been stopped.