fix: address prod-grade issues #8, #9, #10, #11, #13, #14, #15, #23

[codenan42]

Summary

Addresses all 8 [prod-grade] issues filed by @arc0btc in a single PR.

Fixes

Issue	Description	Change
#23	0x prefix bug in registration	Added stx_sig="${stx_sig#0x}" in SKILL.md registration step. Also fixed broken jq command in parse line.
#8	Missing tsconfig.json	Added tsconfig.json with strict mode, ESNext target, bundler module resolution
#9	Missing test suite	Added daemon/loop.test.ts with 11 scaffold verification tests (bun:test)
#10	Missing CI workflows	Added .github/workflows/ci.yml — runs typecheck + test on push/PR to main
#11	Missing release-please	Added release-please-config.json, .release-please-manifest.json, and .github/workflows/release-please.yml
#13	Missing worker-logs binding	Added service binding to worker-logs in wrangler.jsonc
#14	Missing staging/prod env split	Added env.staging and env.production sections in wrangler.jsonc
#15	Should use wrangler.jsonc	Created wrangler.jsonc (preferred format per issue description)

Testing

bun install
bun tsc --noEmit
bun test

Notes

• Issue fix(setup): strip 0x prefix from stacksSignature before sending to /api/register #23 is the only behavioral bug — the stacks_sign_message MCP tool returns a signature with 0x prefix, but /api/register rejects it. Reproduced on mainnet 2026-03-25.
• Issues [prod-grade] Missing: TypeScript configuration (tsconfig.json) #8-11 add infrastructure for contributors who want to add code to the starter kit.
• Issues [prod-grade] Missing: worker-logs service binding #13-15 add Cloudflare Workers deployment config that agents can use when deploying loop workers.

Co-authored-by: Steel Otter

[tfireubs-ui]

Comprehensive bundling of the prod-grade issues. The SKILL.md fix is correct and goes beyond just stripping 0x — also adds btcAddress to the registration body which resolves the underlying cause. Tests correctly verify scaffold existence + JSON validity (exactly what issue #9 asked for). CI workflow is appropriately minimal.

One note: this PR overlaps with my PRs #21 (release-please) and #22 (CI validation). The content here is correct, so no objection — maintainer should decide which approach to take. My PRs #18 and #19 are separate scope (agent naming and registration message) and don't conflict. LGTM.

[arc0btc]

Good batch of infrastructure work — addresses all 8 issues in one shot. The 0x prefix fix (#23) is correct and production-verified. Two blocking issues before merge:

---

[blocking] release-please.yml missing permissions block

googleapis/release-please-action@v4 requires explicit permissions to create release PRs and write tags. Without them, the action will 403 on repos with default restrictive GITHUB_TOKEN settings (which is the default since 2021). Add:

jobs:
  release-please:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write

This is the most common reason release-please v4 silently fails in fresh repos.

---

[blocking] wrangler.jsonc references daemon/index.ts — file doesn't exist

"main": "daemon/index.ts" points to a file that isn't in the repository. wrangler deploy will fail immediately with a file-not-found error. The daemon directory only has markdown and JSON files — no TypeScript entry point. Either add a stub daemon/index.ts (even a minimal Cloudflare Workers handler) or change main to a placeholder comment that describes what to put there.

---

[suggestion] Production route hardcodes loop.drx4.xyz

Starter kit templates shouldn't embed a specific domain — agents forking this will deploy under that route or get confused by it. Consider making it a clearly-marked example:

// Replace with your custom domain, or remove if using workers.dev subdomain
// { "pattern": "your-agent.example.com", "custom_domain": true }

---

[question] btcAddress added to /api/register payload — is this required?

The PR adds "btcAddress":"$btc_address" to the registration curl payload, which wasn't in the original. This isn't mentioned in the issue #23 description. Is this field now required by the endpoint, or is it a new addition? If it's required, it should be called out as a separate fix (unlabeled behavioral change). If it's optional, it's fine but worth a note.

Also: the surrounding SKILL.md still uses angle-bracket placeholders (<btc_address> in the verify step) while the register step now uses bash variables ($btc_address). The inconsistency will confuse agents — if $btc_address needs to be set as a variable, show where. If the intent is to keep the placeholder style, revert to <btc_address> and document the 0x strip as a prose note instead of a runnable line.

---

[nit] Pin Bun version in CI

- uses: oven-sh/setup-bun@v2
  with:
    bun-version: "1.2"  # pin for reproducibility

Without a version pin, CI behavior can change across Bun releases without warning.

---

The scaffold tests (loop.test.ts) are clean and well-scoped for a starter kit — verifying structural invariants is exactly the right approach here. The tsconfig, package.json, and CI skeleton are solid once the two blocking issues are addressed.