feat(wrangler): add SERVICE_SCOPE_DB hyperdrive binding

[chitcommit]

Summary

• Adds SERVICE_SCOPE_DB Hyperdrive binding (id 89158b50e55a4d5d9279b5d5c890ea7b) to both wrangler.jsonc and deploy/system-wrangler.jsonc.
• Pairs with the existing CHITTYOS_CORE_DB binding so the fractal scope projector can write authoritative scopes to the service's own DB and project into ChittyOS-Core.
• Required by chittyschema/identity/scripts/validate-fractal-scopes.ts (it errors on missing SERVICE_SCOPE_DB).
• Removes drift between the two wrangler files (root was missing the binding deploy/ already had locally).

Why

The shared scope projector (@chittyos/schema/scope-projector, wired in server/lib/central-workflows.ts via PR #103) reads env.SERVICE_SCOPE_DB?.connectionString and falls back to SERVICE_SCOPE_DATABASE_URL. With this binding in place, scope writes go through Hyperdrive instead of the env-var fallback path.

Validation

$ npx tsx identity/scripts/validate-fractal-scopes.ts --wrangler .../chittyfinance/wrangler.jsonc
All checks passed.  (exit 0)

$ npx tsx identity/scripts/validate-fractal-scopes.ts --wrangler .../chittyfinance/deploy/system-wrangler.jsonc
All checks passed.  (exit 0)

Test plan

• validate-fractal-scopes.ts passes for both wrangler files
• Post-deploy: confirm Worker boot logs show both Hyperdrive bindings resolving
• Post-deploy: trigger a scope projection and verify a row lands in the service-DB scopes table (in addition to the existing Core projection)

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Added a new database resource in the production environment for managing service-specific scopes, enabling enhanced scope projection capabilities across the system.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	chittyfinance	765f62c	Apr 30 2026, 07:08 PM

[github-actions]

@coderabbitai review

Please evaluate:

• Security implications
• Credential exposure risk
• Dependency supply chain concerns
• Breaking API changes

[coderabbitai]

Caution

Review failed

Pull request was closed or merged during review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 69c50d6b-92bc-4bd2-acb2-50b47598dda7

📥 Commits

Reviewing files that changed from the base of the PR and between 26bfaa7 and 765f62c.

📒 Files selected for processing (2)

• deploy/system-wrangler.jsonc
• wrangler.jsonc

---

📝 Walkthrough

Walkthrough

This PR adds a second Hyperdrive database binding named SERVICE_SCOPE_DB to both the main Worker configuration and the production deployment setup. The binding is introduced alongside the existing CHITTYOS_CORE_DB, with updated documentation clarifying their respective roles in fractal scope projection.

Changes

Cohort / File(s)	Summary
Configuration Files deploy/system-wrangler.jsonc, wrangler.jsonc	Added SERVICE_SCOPE_DB Hyperdrive binding alongside existing CHITTYOS_CORE_DB. Updated comments to document that bindings support fractal scope projection, with CHITTYOS_CORE_DB used for ChittyOS-Core aggregation and SERVICE_SCOPE_DB representing authoritative scopes. Created explicit hyperdrive binding block in production environment.

Estimated Code Review Effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly Related PRs

• chittyapps/chittyfinance#63: Related work on making environment blocks self-contained by declaring bindings explicitly within production configurations, similar to the approach taken here for Hyperdrive bindings.

Poem

🐰 A database joins the rabbit's warren of bindings,
SERVICE_SCOPE_DB hops alongside its kin,
Fractal scopes now leap through config so fine,
Two Hyperdrives dance in production's design! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: adding a SERVICE_SCOPE_DB hyperdrive binding to the Wrangler configuration files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/service-scope-db-binding

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Review rate limit: 0/1 reviews remaining, refill in 60 minutes.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Code Review — PR #110: feat(wrangler): add SERVICE_SCOPE_DB hyperdrive binding

The intent is clear and the binding ID itself looks correct. However, there are several gaps that will cause this to silently fail at runtime.

---

Critical: Per-env blocks are missing the binding in wrangler.jsonc

Both wrangler files include this warning in their header:

Bindings (KV, R2, DO, tail_consumers) do NOT inherit from top-level into env blocks — each env must carry its own explicit bindings.

In wrangler.jsonc, the new hyperdrive array was added only at the top level. The env.dev, env.staging, and env.production blocks have no hyperdrive entry at all — meaning wrangler dev --env dev, wrangler deploy --env staging, and wrangler deploy --env production will all boot without SERVICE_SCOPE_DB (and without CHITTYOS_CORE_DB, which had the same gap pre-existing).

In deploy/system-wrangler.jsonc, env.production was correctly updated, but env.dev and env.staging were not. Same problem for those two environments.

Each named env block needs:

"hyperdrive": [
  { "binding": "CHITTYOS_CORE_DB", "id": "1d126444cff1416cb415447e6cc6d15a" },
  { "binding": "SERVICE_SCOPE_DB",  "id": "89158b50e55a4d5d9279b5d5c890ea7b" }
]

---

Critical: server/env.ts is missing both Hyperdrive binding types

Neither CHITTYOS_CORE_DB nor SERVICE_SCOPE_DB are declared in the Env interface. Without them, env.SERVICE_SCOPE_DB is untyped — TypeScript won't catch misuse, and in strict mode this is a compile error. Add:

CHITTYOS_CORE_DB: Hyperdrive;
SERVICE_SCOPE_DB:  Hyperdrive;

(Hyperdrive is available from @cloudflare/workers-types.)

---

Medium: SERVICE_SCOPE_DATABASE_URL fallback not in Env

The PR description says the scope projector falls back to env.SERVICE_SCOPE_DATABASE_URL when the Hyperdrive binding isn't present. That variable isn't listed in Env, so it's invisible to TypeScript and won't be documented for ops. Follow the existing pattern of CHITTYOS_CORE_DATABASE_URL:

SERVICE_SCOPE_DATABASE_URL?: string;

---

Low: Stale comment in deploy/system-wrangler.jsonc

The top-level hyperdrive comment still reads "Hyperdrive binding for fractal scope projection into ChittyOS-Core" (singular). It should be updated to match the new wrangler.jsonc comment describing both bindings, since deploy/system-wrangler.jsonc now also carries two bindings.

---

On the validator

The test plan shows validate-fractal-scopes.ts passing, but that script appears to check the top-level wrangler config. Since per-env blocks don't inherit top-level bindings, passing top-level validation doesn't prove the named environments will work. Consider whether the validator checks per-env blocks, or if a post-deploy boot log check is the only real gate here.

---

Summary

Issue	Severity
env.dev/env.staging/env.production blocks missing hyperdrive in wrangler.jsonc	Critical
env.dev/env.staging blocks missing hyperdrive in deploy/system-wrangler.jsonc	Critical
Env interface missing CHITTYOS_CORE_DB and SERVICE_SCOPE_DB Hyperdrive types	Critical
SERVICE_SCOPE_DATABASE_URL fallback not in Env	Medium
Stale comment in deploy/system-wrangler.jsonc top-level hyperdrive block	Low

The binding ID and the production env block in deploy/system-wrangler.jsonc are correct — the fix is mostly additive (copy the hyperdrive array into the remaining env blocks and update env.ts).

[Copilot]

Pull request overview

Adds a new Cloudflare Hyperdrive binding (SERVICE_SCOPE_DB) to the Workers configs so the shared scope projector can write authoritative scopes into the service DB (and continue projecting into ChittyOS-Core).

Changes:

• Add SERVICE_SCOPE_DB Hyperdrive binding to wrangler.jsonc.
• Add SERVICE_SCOPE_DB Hyperdrive binding to deploy/system-wrangler.jsonc (top-level and env.production).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
wrangler.jsonc	Adds SERVICE_SCOPE_DB Hyperdrive binding alongside CHITTYOS_CORE_DB at the top level.
deploy/system-wrangler.jsonc	Adds SERVICE_SCOPE_DB Hyperdrive binding at the top level and within env.production.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

wrangler.jsonc has explicit env blocks, and the header comment notes certain bindings do not inherit into env blocks. Right now the new Hyperdrive bindings are only declared at the top level, so wrangler deploy --env production (and any other env deploys) may run without SERVICE_SCOPE_DB/CHITTYOS_CORE_DB bound. To avoid missing bindings at runtime, duplicate this hyperdrive array into the relevant env.* blocks (at minimum env.production, and any envs where scope projection should work).

[Copilot]

The comment above the hyperdrive block still says “binding” and mentions only projection into ChittyOS-Core, but the config now declares two bindings (Core + SERVICE_SCOPE_DB). Update the comment to reflect both bindings (and optionally the validate-fractal-scopes requirement) so future edits don’t miss one of them.