Set up KKL fork releases and upstream sync

[baby-joel]

Goal

Make KnickKnackLabs/pi usable as our installable Pi fork while staying close to earendil-works/pi.

Initial release posture

• Publish GitHub Release binaries from the fork.
• Do not publish npm packages initially; upstream owns @earendil-works/*.
• Spike the exact mise install shape so users can keep the command name pi while sourcing releases from KnickKnackLabs/pi.
• Keep release/tagging human-gated until the process is proven.

Upstream sync posture

• Keep remotes/branches shaped like:
  • upstream/main = earendil-works/pi
  • origin/upstream = mirrored upstream main/tag baseline
  • origin/main = upstream plus KKL patches
• Add scheduled/manual CI that detects upstream tags/main movement and opens sync PRs into KKL main.
• Sync PRs should run the normal Pi validation before merge.
• After sync PR review/merge, manually trigger a KKL release tag like vX.Y.Z-kkl.N.

Open questions

• Should KKL releases mirror upstream version numbers with -kkl.N, or use a separate monotonic fork version?
• Should the fork release workflow reuse upstream build-binaries.yml with npm publish disabled, or have a dedicated KKL workflow?
• What is the cleanest mise config syntax for installing pi from github:KnickKnackLabs/pi releases?

Decision: fork version string

Use explicit fork versions like v0.79.0-kkl.1 and make the built binary report the same version. This matches the existing KKL fork convention and keeps provenance visible in pi --version, release artifacts, and bug reports.

[baby-joel]

Follow-up notes from the manual v0.79.6-kkl.1 sync/release:

Current fork posture

• main is synced through upstream v0.79.6 via Sync upstream v0.79.6 into KKL main #9.
• Latest KKL release is v0.79.6-kkl.1.
• KKL release workflow is manual and uploads SHA256SUMS.
• Keep KKL release tags/adoption human-gated.

Automation shape for next slice

Desired workflow: scheduled + manual upstream detector that opens a sync PR, not a release.

Inputs/state:

• Upstream remote: earendil-works/pi.
• Fork main: KnickKnackLabs/pi@main.
• Preferred sync target: latest upstream release tag, not arbitrary post-tag upstream/main, unless explicitly requested.
• Release tag shape: upstream vX.Y.Z -> KKL package version/tag vX.Y.Z-kkl.1 for the first fork release on that upstream base.

Workflow steps:

1. Discover latest upstream non-prerelease release/tag from earendil-works/pi.
2. Compare it to the latest KKL release base (v*-kkl.N -> strip -kkl.N).
3. If no newer upstream tag exists, exit cleanly.
4. If a sync PR for that upstream tag already exists, update/comment or exit cleanly.
5. Create/update a branch like sync/upstream-vX.Y.Z from current KKL main.
6. Merge upstream tag vX.Y.Z into the branch.
7. Resolve expected fork conflicts mechanically where safe:
   • keep KKL deletion of inherited upstream publish/gate workflows;
   • keep/update .github/workflows/release-kkl.yml;
   • set workspace/package versions to X.Y.Z-kkl.1;
   • refresh package-lock.json and packages/coding-agent/npm-shrinkwrap.json.
8. Open a PR into KKL main with:
   • upstream target tag;
   • KKL target version;
   • conflict-resolution summary;
   • validation expectations.
9. Let normal PR CI validate. Do not tag or release automatically.

Token/CI caveat

If the workflow uses the built-in GITHUB_TOKEN to push the branch/open the PR, GitHub may suppress follow-on workflow runs triggered by that token. Options to evaluate:

• Use GITHUB_TOKEN and explicitly trigger validation with workflow_run/manual dispatch if needed.
• Use a fine-scoped PAT/App token so PR CI behaves like a normal pushed branch.
• Keep auto-detection as issue/comment-only until token policy is decided.

Follow-up fixes worth splitting

• test.sh currently moves ~/.pi/agent/auth.json globally for no-auth tests. That is hazardous on Or's machine because it can break concurrent Pi agent launches. Prefer an isolated temp PI_CODING_AGENT_DIR/home/auth fixture so local validation does not mutate live auth.
• The 5303 stdio-grace tweak carried in Sync upstream v0.79.6 into KKL main #9 is KKL-only for now. Do not open an upstream PR from that branch directly; if upstreaming later, prepare a clean upstream-targeted PR and revisit whether a wider grace or a more precise pending-stdio timer is the right shape.

This comment is AI-generated by Baby Joel.