docs: migration roadmap (phases 2b–4) + canonical triad refresh#35
docs: migration roadmap (phases 2b–4) + canonical triad refresh#35chitcommit wants to merge 1 commit into
Conversation
Adds docs/migrations/ index and per-phase plans for the Express → Hono Workers migration. Refreshes top-level CLAUDE.md with the current migration posture (Tier 4, ChittyAuth, Hyperdrive binding CHITTYASSETS_DB, GCS → R2 cutover, P/L/T/E/A entity types). Files: - docs/migrations/ROADMAP.md — phase index, dependency graph, PR status - docs/migrations/phase2b-simple-reads.md - docs/migrations/phase2c-external-reads.md - docs/migrations/phase3a-asset-writes.md - docs/migrations/phase3b-domain-writes.md - docs/migrations/phase3c-heavy-writes.md - docs/migrations/phase4-r2-routes.md - docs/migrations/test-strategy.md — real-Neon no-mocks harness - docs/migrations/registry-status.md — chittyassets NOT REGISTERED - CLAUDE.md — migration-status section added at top Read-only on code: no .ts/.tsx/.js/.json/.toml/.jsonc/.sql touched. Does not duplicate CHARTER.md/CHITTY.md (they land via PR #33). Route citations reference server/routes.ts line numbers. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughThis PR adds comprehensive migration documentation for the ChittyAssets Express-to-Cloudflare Workers platform transition. It specifies phases 2b through 4, defines entity models, API scope, worker layouts, zod validation schemas, external service integrations, storage migration, testing requirements, and registry finalization. ChangesChittyAssets Express-to-Workers Migration Documentation
Sequence Diagram(s)No diagrams generated: this PR is documentation-only, specifying phases and implementation contracts without introducing new runtime flows or multi-component interactions requiring visualization at this stage. Estimated code review effort🎯 1 (Trivial) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f8adce31b4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| When the last phase merges, `server/index.ts`, `server/routes.ts`, and the | ||
| Express middleware chain can be deleted; the Worker becomes the sole runtime. |
There was a problem hiding this comment.
Before removing the Express runtime, this roadmap needs to account for GitHub App endpoints that are currently outside the phase plans: setupGitHubWebhooks(app) is still invoked in server/routes.ts and registers /api/github/webhooks, /api/github/callback, and /api/github/setup in server/githubWebhooks.ts (lines 316–340). As written, deleting the Express middleware chain after Phase 4 would drop those routes entirely, causing a functional regression for webhook/OAuth flows.
Useful? React with 👍 / 👎.
| .from(warranties) | ||
| .innerJoin(assets, eq(warranties.assetId, assets.id)) | ||
| .where(and(eq(warranties.assetId, assetId), eq(assets.userId, userId))) | ||
| .orderBy(warranties.expirationDate); |
There was a problem hiding this comment.
The Drizzle pseudocode uses warranties.expirationDate, but the actual schema defines warranties.endDate (shared/schema.ts), and current storage logic also filters/sorts by endDate. If implementers follow this example literally, Phase 2b query code will not compile and can drift from existing API behavior for expiring-warranty filtering.
Useful? React with 👍 / 👎.
|
|
||
| export const CreateAssetSchema = z.object({ | ||
| name: z.string().min(1).max(200), | ||
| assetType: z.enum(['vehicle','property','jewelry','electronics','art','document','other']), |
There was a problem hiding this comment.
The proposed CreateAssetSchema enum diverges from the live DB-backed asset types (shared/schema.ts has values like real_estate, artwork, documents, business_assets, etc.). Following this snippet will both reject currently valid asset types and allow values like property/document/art that do not exist in the database enum, causing write-path failures or behavior drift in Phase 3a.
Useful? React with 👍 / 👎.
|
|
||
| 1. `services.id.generate('asset')` → ChittyID matching `CHITTY_ID_PATTERN` | ||
| 2. `services.trust.calculate(chittyId, payload)` → trustScore (Authority, A) | ||
| 3. `db.transaction(tx => { insertAsset(tx, …); insertTimelineEvent(tx, { eventType: 'created' }); })` |
There was a problem hiding this comment.
This flow instructs eventType: 'created', but 'created' is not a valid timeline_event_type in shared/schema.ts (and the current route uses 'acquisition' for asset creation). Implementing this literally would break the create-asset transaction when inserting timeline rows under Phase 3a.
Useful? React with 👍 / 👎.
| 2. Real-Neon integration test (ephemeral branch): | ||
| - Create asset → assert ChittyID matches `CHITTY_ID_PATTERN` | ||
| - Update asset → assert `updated_at` advanced + timeline event row exists | ||
| - Delete asset → assert soft-delete flag set, list endpoint excludes it |
There was a problem hiding this comment.
The validation checklist requires asserting a soft-delete flag, but current storage and schema use hard delete (storage.deleteAsset() issues db.delete(...), and assets has no soft-delete column). Keeping this gate as written makes the Phase 3a acceptance criteria internally inconsistent with the referenced source behavior and can block implementation on a nonexistent field.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (10)
docs/migrations/phase4-r2-routes.md (1)
17-21: ⚡ Quick winUnify route pattern notation across sections.
Line 19 (
:objectPath(*)), Line 72 (:path(*)), and Line 75 (:path{.+}) describe the same route with different syntaxes/names. Pick one canonical form to reduce migration ambiguity.Also applies to: 72-76
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/migrations/phase4-r2-routes.md` around lines 17 - 21, The document uses three different route parameter syntaxes (`:objectPath(*)`, `:path(*)`, and `:path{.+}`); pick one canonical form (e.g., `:path(*)`) and replace all occurrences in this markdown (including the table row listing GET `/objects/:objectPath(*)` and the other examples around the `:path` usages) so the route pattern notation is consistent across the file; ensure any explanatory text or code references (e.g., in examples or mentions of `/objects` or `/api/objects/upload`) are updated to use the chosen parameter name and syntax throughout.docs/migrations/registry-status.md (1)
55-57: ⚡ Quick winReplace machine-local contract path with a portable reference.
Line 56 uses
/home/ubuntu/..., which is environment-specific and likely invalid for most operators. Prefer a canonical URI or repo-relative pointer so the instruction is reproducible.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/migrations/registry-status.md` around lines 55 - 57, Replace the environment-specific path `/home/ubuntu/.ch1tty/canon/system-wide-sensitive-intent-contract-v1.md` with a portable canonical reference (e.g., a repo-relative pointer or canonical URI) so the doc is reproducible; update the line to reference the contract by its canonical name such as `docs/contracts/system-wide-sensitive-intent-contract-v1.md` or a stable URI (e.g., `https://repo.example.com/.../system-wide-sensitive-intent-contract-v1.md`) and keep the inline code formatting used for the original path.docs/migrations/phase2c-external-reads.md (2)
43-67: ⚡ Quick winDefine or document the
LedgerErrorclass.Line 63 throws a
LedgerErrorthat is not defined in the pseudocode snippet. To complete the contract specification, either include the class definition or add a comment indicating where it should be defined.📋 Suggested addition
Add before or after the
ChittyLedgerClientclass:export class LedgerError extends Error { constructor(public statusCode: number, message: string) { super(`Ledger request failed (${statusCode}): ${message}`); this.name = 'LedgerError'; } }Or add a documentation comment:
// Throws LedgerError (defined in worker/src/lib/errors.ts) on non-OK responses if (!res.ok) throw new LedgerError(res.status, await res.text());🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/migrations/phase2c-external-reads.md` around lines 43 - 67, The snippet throws an undefined LedgerError in ChittyLedgerClient.getEvidence; either add a simple exported LedgerError class (e.g., extends Error with a public statusCode property, constructor(statusCode:number, message:string) that sets name='LedgerError' and a descriptive message) near the ChittyLedgerClient definition, or add a one-line documentation comment above getEvidence stating where LedgerError is defined/imported so callers know the contract; ensure the class is exported and referenced as LedgerError so the throw compiles and the error includes the HTTP status and response text.
90-100: ⚡ Quick winClarify retry count and backoff sequence.
Lines 93-94 state "2 retries" with "exponential backoff 100ms → 300ms". This could be interpreted as either 2 total attempts (1 retry) or 3 total attempts (2 retries). For implementation clarity, specify the total number of attempts and the exact backoff sequence.
📋 Suggested clarification
Replace:
- **Retries**: 2 retries on 5xx or network error, exponential backoff 100ms → 300ms; no retry on 4xxWith one of:
- **Retries**: Up to 2 retry attempts (3 total attempts) on 5xx or network error, with exponential backoff (100ms after first failure, 300ms after second failure); no retry on 4xxOr if the intent is truly 1 retry:
- **Retries**: 1 retry attempt (2 total attempts) on 5xx or network error, with 100ms backoff; no retry on 4xx🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/migrations/phase2c-external-reads.md` around lines 90 - 100, Update the "- **Retries**" bullet to explicitly state total attempts and exact backoff sequence so implementers aren’t left guessing; replace the ambiguous line with either (A) "Up to 2 retry attempts (3 total attempts) on 5xx or network error, with exponential backoff — 100ms after first failure, 300ms after second; no retry on 4xx" if the policy is two retries, or (B) "1 retry attempt (2 total attempts) on 5xx or network error, with 100ms backoff; no retry on 4xx" if the intent is a single retry, and ensure the updated text replaces the existing "- **Retries**" bullet in the doc.docs/migrations/ROADMAP.md (1)
35-35: ⚡ Quick winAdd language specifier to fenced code block.
The fenced code block is missing a language specifier, which triggers a markdownlint warning (MD040). Add
textto the opening fence.📝 Proposed fix
-``` +```text chittyassets (Tier 4)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/migrations/ROADMAP.md` at line 35, The fenced code block containing the line "chittyassets (Tier 4)" is missing a language specifier which triggers MD040; update the opening triple backtick to ```text so the block becomes a language-specified fenced code block (e.g., change ``` to ```text for the block that wraps "chittyassets (Tier 4)").docs/migrations/test-strategy.md (1)
87-88: 💤 Low valueSimplify the environment variable check.
Line 87 uses the non-null assertion operator
!, but line 88 immediately checks if the value is falsy. The non-null assertion doesn't provide runtime safety, so checking afterward makes the assertion unnecessary.♻️ Proposed simplification
- testDbUrl = process.env.CHITTYASSETS_DB_TEST_URL!; - if (!testDbUrl) throw new Error('CHITTYASSETS_DB_TEST_URL required — real Neon branch only, no mocks'); + const envUrl = process.env.CHITTYASSETS_DB_TEST_URL; + if (!envUrl) throw new Error('CHITTYASSETS_DB_TEST_URL required — real Neon branch only, no mocks'); + testDbUrl = envUrl;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/migrations/test-strategy.md` around lines 87 - 88, Remove the unnecessary non-null assertion on process.env.CHITTYASSETS_DB_TEST_URL: assign testDbUrl from process.env.CHITTYASSETS_DB_TEST_URL without the trailing "!" and keep the existing runtime check (if (!testDbUrl) throw new Error(...)); ensure you reference the same variable name testDbUrl and the environment key CHITTYASSETS_DB_TEST_URL so the runtime validation remains the single source of truth.docs/migrations/phase3a-asset-writes.md (2)
31-45: ⚡ Quick winAdd service client modules to the file layout.
Lines 74-75 reference
services.id.generate('asset')andservices.trust.calculate(chittyId, payload), but the file layout doesn't include aservices/directory or these client modules. Implementers will need guidance on where to place ChittyID and ChittyTrust service clients.📂 Suggested addition to file layout
worker/src/ + services/ + chittyid.ts # ChittyID generation service client + chittytrust.ts # Trust score calculation service client routes/ assets-write.ts # POST, PUT, DELETE /api/assets[/:id] evidence-write.ts # POST /api/assets/:assetId/evidence🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/migrations/phase3a-asset-writes.md` around lines 31 - 45, Add a services/ directory to the file layout and document two client modules: services/chitty-id.ts exporting a ChittyID client used by services.id.generate('asset') and services/chitty-trust.ts exporting a ChittyTrust client used by services.trust.calculate(chittyId, payload); place them under worker/src/services/ and describe their expected surface (e.g., generate(idType) or calculate(chittyId, payload)) so implementers know where to implement and wire the clients referenced in the diff.
33-33: ⚡ Quick winAdd language specifier to fenced code block.
Markdown linters prefer an explicit language identifier on fenced code blocks. For directory structure listings, use
text.📝 Proposed fix
-``` +```text worker/src/🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/migrations/phase3a-asset-writes.md` at line 33, The fenced code block containing the directory listing (the triple backticks followed by the line "worker/src/") is missing a language specifier; update the block opener from ``` to ```text so the markdown linter recognizes it as a plain text block and renders the directory structure correctly.docs/migrations/phase3c-heavy-writes.md (1)
39-39: ⚡ Quick winAdd language specifier to fenced code block.
Markdown linters prefer an explicit language identifier. For directory structure, use
text.📝 Proposed fix
-``` +```text worker/src/🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/migrations/phase3c-heavy-writes.md` at line 39, Update the fenced code block containing the directory snippet "worker/src/" in docs/migrations/phase3c-heavy-writes.md to include an explicit language specifier; replace the opening ``` with ```text so the block becomes a text-formatted code fence (leave the block contents unchanged).docs/migrations/phase3b-domain-writes.md (1)
38-38: ⚡ Quick winAdd language specifier to fenced code block.
Markdown linters prefer an explicit language identifier. For directory structure, use
text.📝 Proposed fix
-``` +```text worker/src/routes/🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/migrations/phase3b-domain-writes.md` at line 38, The fenced code block containing the directory listing "worker/src/routes/" needs an explicit language tag for the markdown linter; update the fence that currently uses ``` to use ```text so it reads as a text block, ensuring the directory snippet is marked as text rather than an untyped fence.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/migrations/phase2b-simple-reads.md`:
- Around line 30-40: The fenced code block showing the file layout lacks a
language specifier; update that block to include a language (e.g., plaintext or
text) so the snippet renders correctly and satisfies markdownlint—modify the
fenced block that lists worker/src/routes/ (warranties.ts, insurance.ts,
legal-cases.ts, tools.ts) and worker/src/db/queries (queries/warranties.ts,
queries/insurance.ts, queries/legal-cases.ts) to start with ```plaintext (or
another appropriate language).
In `@docs/migrations/phase2c-external-reads.md`:
- Around line 29-37: The fenced code block showing the project layout
(containing lines like "worker/src/", "clients/chittyledger.ts",
"routes/evidence-ledger.ts", etc.) lacks a language specifier; update that block
to include a language label (e.g., "plaintext") on the opening triple-backticks
so the snippet renders properly and fixes the markdownlint warning.
In `@docs/migrations/phase3c-heavy-writes.md`:
- Around line 76-77: Update the sentence "Cloudflare Worker request CPU limit is
~30s on paid plans." to clarify that 30s is the default for HTTP requests on
Paid (Standard) plans but is configurable up to 300s (5 minutes) via Wrangler or
the Cloudflare dashboard, and also add the Cron Trigger distinction: 30s for
intervals <1 hour and 15 minutes for intervals >=1 hour on paid plans; reference
this clarification where the document discusses the sync vs. queue decision so
readers understand the configurable limits and differing Cron Trigger behavior.
In `@docs/migrations/phase4-r2-routes.md`:
- Around line 38-45: The fenced code block listing worker/src routes and storage
files (showing objects.ts, r2-acl.ts, r2-upload.ts) is missing a language tag
which triggers markdownlint MD040; fix it by adding a language identifier (e.g.,
```text) to the opening fence of that block in the migration doc so the block
renders and lints correctly, leaving the block content unchanged.
---
Nitpick comments:
In `@docs/migrations/phase2c-external-reads.md`:
- Around line 43-67: The snippet throws an undefined LedgerError in
ChittyLedgerClient.getEvidence; either add a simple exported LedgerError class
(e.g., extends Error with a public statusCode property,
constructor(statusCode:number, message:string) that sets name='LedgerError' and
a descriptive message) near the ChittyLedgerClient definition, or add a one-line
documentation comment above getEvidence stating where LedgerError is
defined/imported so callers know the contract; ensure the class is exported and
referenced as LedgerError so the throw compiles and the error includes the HTTP
status and response text.
- Around line 90-100: Update the "- **Retries**" bullet to explicitly state
total attempts and exact backoff sequence so implementers aren’t left guessing;
replace the ambiguous line with either (A) "Up to 2 retry attempts (3 total
attempts) on 5xx or network error, with exponential backoff — 100ms after first
failure, 300ms after second; no retry on 4xx" if the policy is two retries, or
(B) "1 retry attempt (2 total attempts) on 5xx or network error, with 100ms
backoff; no retry on 4xx" if the intent is a single retry, and ensure the
updated text replaces the existing "- **Retries**" bullet in the doc.
In `@docs/migrations/phase3a-asset-writes.md`:
- Around line 31-45: Add a services/ directory to the file layout and document
two client modules: services/chitty-id.ts exporting a ChittyID client used by
services.id.generate('asset') and services/chitty-trust.ts exporting a
ChittyTrust client used by services.trust.calculate(chittyId, payload); place
them under worker/src/services/ and describe their expected surface (e.g.,
generate(idType) or calculate(chittyId, payload)) so implementers know where to
implement and wire the clients referenced in the diff.
- Line 33: The fenced code block containing the directory listing (the triple
backticks followed by the line "worker/src/") is missing a language specifier;
update the block opener from ``` to ```text so the markdown linter recognizes it
as a plain text block and renders the directory structure correctly.
In `@docs/migrations/phase3b-domain-writes.md`:
- Line 38: The fenced code block containing the directory listing
"worker/src/routes/" needs an explicit language tag for the markdown linter;
update the fence that currently uses ``` to use ```text so it reads as a text
block, ensuring the directory snippet is marked as text rather than an untyped
fence.
In `@docs/migrations/phase3c-heavy-writes.md`:
- Line 39: Update the fenced code block containing the directory snippet
"worker/src/" in docs/migrations/phase3c-heavy-writes.md to include an explicit
language specifier; replace the opening ``` with ```text so the block becomes a
text-formatted code fence (leave the block contents unchanged).
In `@docs/migrations/phase4-r2-routes.md`:
- Around line 17-21: The document uses three different route parameter syntaxes
(`:objectPath(*)`, `:path(*)`, and `:path{.+}`); pick one canonical form (e.g.,
`:path(*)`) and replace all occurrences in this markdown (including the table
row listing GET `/objects/:objectPath(*)` and the other examples around the
`:path` usages) so the route pattern notation is consistent across the file;
ensure any explanatory text or code references (e.g., in examples or mentions of
`/objects` or `/api/objects/upload`) are updated to use the chosen parameter
name and syntax throughout.
In `@docs/migrations/registry-status.md`:
- Around line 55-57: Replace the environment-specific path
`/home/ubuntu/.ch1tty/canon/system-wide-sensitive-intent-contract-v1.md` with a
portable canonical reference (e.g., a repo-relative pointer or canonical URI) so
the doc is reproducible; update the line to reference the contract by its
canonical name such as
`docs/contracts/system-wide-sensitive-intent-contract-v1.md` or a stable URI
(e.g.,
`https://repo.example.com/.../system-wide-sensitive-intent-contract-v1.md`) and
keep the inline code formatting used for the original path.
In `@docs/migrations/ROADMAP.md`:
- Line 35: The fenced code block containing the line "chittyassets (Tier 4)" is
missing a language specifier which triggers MD040; update the opening triple
backtick to ```text so the block becomes a language-specified fenced code block
(e.g., change ``` to ```text for the block that wraps "chittyassets (Tier 4)").
In `@docs/migrations/test-strategy.md`:
- Around line 87-88: Remove the unnecessary non-null assertion on
process.env.CHITTYASSETS_DB_TEST_URL: assign testDbUrl from
process.env.CHITTYASSETS_DB_TEST_URL without the trailing "!" and keep the
existing runtime check (if (!testDbUrl) throw new Error(...)); ensure you
reference the same variable name testDbUrl and the environment key
CHITTYASSETS_DB_TEST_URL so the runtime validation remains the single source of
truth.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 03e9cfa9-f08f-4338-b0d9-e07c09aeb2fe
📒 Files selected for processing (10)
CLAUDE.mddocs/migrations/ROADMAP.mddocs/migrations/phase2b-simple-reads.mddocs/migrations/phase2c-external-reads.mddocs/migrations/phase3a-asset-writes.mddocs/migrations/phase3b-domain-writes.mddocs/migrations/phase3c-heavy-writes.mddocs/migrations/phase4-r2-routes.mddocs/migrations/registry-status.mddocs/migrations/test-strategy.md
| ``` | ||
| worker/src/routes/ | ||
| warranties.ts # GET /api/assets/:assetId/warranties, GET /api/warranties/expiring | ||
| insurance.ts # GET /api/assets/:assetId/insurance | ||
| legal-cases.ts # GET /api/legal-cases | ||
| tools.ts # GET /api/tools/resources | ||
| worker/src/db/ | ||
| queries/warranties.ts | ||
| queries/insurance.ts | ||
| queries/legal-cases.ts | ||
| ``` |
There was a problem hiding this comment.
Add language specifier to fenced code block.
The file layout section uses a fenced code block without a language specifier. Adding one improves rendering and addresses the markdownlint warning.
📝 Proposed fix
-```
+```plaintext
worker/src/routes/
warranties.ts # GET /api/assets/:assetId/warranties, GET /api/warranties/expiring
insurance.ts # GET /api/assets/:assetId/insurance🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 30-30: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/migrations/phase2b-simple-reads.md` around lines 30 - 40, The fenced
code block showing the file layout lacks a language specifier; update that block
to include a language (e.g., plaintext or text) so the snippet renders correctly
and satisfies markdownlint—modify the fenced block that lists worker/src/routes/
(warranties.ts, insurance.ts, legal-cases.ts, tools.ts) and
worker/src/db/queries (queries/warranties.ts, queries/insurance.ts,
queries/legal-cases.ts) to start with ```plaintext (or another appropriate
language).
| ``` | ||
| worker/src/ | ||
| clients/ | ||
| chittyledger.ts # HTTP client for ledger.chitty.cc | ||
| ecosystem.ts # parallel /health probes | ||
| routes/ | ||
| evidence-ledger.ts # GET /api/evidence-ledger/:chittyId | ||
| ecosystem.ts # GET /api/ecosystem/status | ||
| ``` |
There was a problem hiding this comment.
Add language specifier to fenced code block.
The file layout section uses a fenced code block without a language specifier. Adding one improves rendering and addresses the markdownlint warning.
📝 Proposed fix
-```
+```plaintext
worker/src/
clients/
chittyledger.ts # HTTP client for ledger.chitty.cc🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 29-29: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/migrations/phase2c-external-reads.md` around lines 29 - 37, The fenced
code block showing the project layout (containing lines like "worker/src/",
"clients/chittyledger.ts", "routes/evidence-ledger.ts", etc.) lacks a language
specifier; update that block to include a language label (e.g., "plaintext") on
the opening triple-backticks so the snippet renders properly and fixes the
markdownlint warning.
| Cloudflare Worker request CPU limit is ~30s on paid plans. GPT-4o calls for | ||
| legal-doc generation can exceed this. Recommended approach: |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What are the current Cloudflare Workers CPU time limits for different pricing plans in 2026?
💡 Result:
For Cloudflare Workers in 2026, the CPU-time limits depend on the account/pricing model and the type of trigger. Here are the current documented limits. 1) Workers Free plan - CPU time per HTTP request (invocation): 10 ms [1] 2) Workers Paid plan (Standard usage model) - CPU time per HTTP request (invocation): 5 minutes max (default 30 seconds) [1] - CPU time per Cron Trigger: 10 ms (for Free) vs 30 seconds for < 1 hour interval; 15 minutes for >= 1 hour interval (Paid) [1] - You can increase the paid HTTP/request limit from the default 30 seconds up to 5 minutes (300,000 ms) via Wrangler configuration or the dashboard. [1] 3) Unbound/Bundled plans (limits exception noted) - Bundled plan CPU time (HTTP requests): 50 ms [1] - Bundled plan CPU time (Cron Triggers): 50 ms [1] Notes / related pricing variants that also state CPU caps - “Workers for Platforms” Paid plan: max 30 seconds CPU time per invocation and max 15 minutes CPU time per Cron Trigger or Queue Consumer invocation. [2] - Dynamic Workers: CPU time is billed at the same rate as Workers Standard (i.e., it follows the Workers Standard CPU-time model/limits). [3] If you tell me which specific “pricing plans” you mean (e.g., Workers Free vs Workers Paid; or also Bundled/Unbound; or Workers for Platforms vs Dynamic Workers), I can produce a tighter table matching that exact set.
Citations:
- 1: https://developers.cloudflare.com/workers/platform/limits/
- 2: https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/platform/pricing
- 3: https://developers.cloudflare.com/dynamic-workers/pricing/
Clarify Cloudflare Worker CPU limits: 30s is the default, not the hard limit.
The spec states "Cloudflare Worker request CPU limit is ~30s on paid plans." According to current Cloudflare documentation, 30 seconds is the default for HTTP requests on Workers Paid (Standard) plans, but this is configurable up to 5 minutes (300 seconds) via Wrangler configuration or the Cloudflare dashboard. Additionally, Cron Trigger CPU limits differ: 30 seconds for intervals <1 hour, and 15 minutes for intervals >=1 hour on paid plans. This distinction matters for the sync vs. queue decision presented in the migration guide.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/migrations/phase3c-heavy-writes.md` around lines 76 - 77, Update the
sentence "Cloudflare Worker request CPU limit is ~30s on paid plans." to clarify
that 30s is the default for HTTP requests on Paid (Standard) plans but is
configurable up to 300s (5 minutes) via Wrangler or the Cloudflare dashboard,
and also add the Cron Trigger distinction: 30s for intervals <1 hour and 15
minutes for intervals >=1 hour on paid plans; reference this clarification where
the document discusses the sync vs. queue decision so readers understand the
configurable limits and differing Cron Trigger behavior.
| ``` | ||
| worker/src/ | ||
| routes/ | ||
| objects.ts # GET /objects/:path(*), POST /api/objects/upload, PUT /api/evidence-files | ||
| storage/ | ||
| r2-acl.ts # canAccessObject(objectPath, userId, permission) | ||
| r2-upload.ts # createPresignedPut, finalizeUpload (writes acl row) | ||
| ``` |
There was a problem hiding this comment.
Add a language to the fenced block.
Line 38 starts a fenced code block without a language, which triggers markdownlint MD040 and weakens rendering/tooling support.
Suggested diff
-```
+```text
worker/src/
routes/
objects.ts # GET /objects/:path(*), POST /api/objects/upload, PUT /api/evidence-files
storage/
r2-acl.ts # canAccessObject(objectPath, userId, permission)
r2-upload.ts # createPresignedPut, finalizeUpload (writes acl row)</details>
<details>
<summary>🧰 Tools</summary>
<details>
<summary>🪛 markdownlint-cli2 (0.22.1)</summary>
[warning] 38-38: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @docs/migrations/phase4-r2-routes.md around lines 38 - 45, The fenced code
block listing worker/src routes and storage files (showing objects.ts,
r2-acl.ts, r2-upload.ts) is missing a language tag which triggers markdownlint
MD040; fix it by adding a language identifier (e.g., ```text) to the opening
fence of that block in the migration doc so the block renders and lints
correctly, leaving the block content unchanged.
</details>
<!-- fingerprinting:phantom:triton:hawk -->
<!-- This is an auto-generated comment by CodeRabbit -->
1 participant
Summary
Documentation-only PR adding the Express → Cloudflare Workers (Hono) migration roadmap and refreshing the canonical posture of
chittyassets. No code touched — read-only on.ts/.tsx/.js/.json/.toml/.jsonc/.sql. Independent of the active Phase 2a / Phase 1 / schema-remediation stack; merges directly tomain.Files added
docs/migrations/ROADMAP.md— phase index, dependency graph, PR statusdocs/migrations/phase2b-simple-reads.md— warranties, insurance, legal-cases, tools/resourcesdocs/migrations/phase2c-external-reads.md— evidence-ledger get, ecosystem/status (HTTP clients + retry/timeout)docs/migrations/phase3a-asset-writes.md— POST/PUT/DELETE/api/assets, evidence createdocs/migrations/phase3b-domain-writes.md— warranty/insurance/legal-case createsdocs/migrations/phase3c-heavy-writes.md— freeze, mint, AI, ledger writes, seed-demodocs/migrations/phase4-r2-routes.md— R2 cutover, ACL modeldocs/migrations/test-strategy.md— real-Neon no-mocks harnessdocs/migrations/registry-status.md— ChittyRegistry status (NOT REGISTERED)Files modified
CLAUDE.md— added migration-status section + canonical annotation. Legacy "Replit Auth"/"Google Cloud Storage" descriptions retained as historical context; new section above flags them as the legacy stack being replaced.Registry status
GET https://registry.chitty.cc/api/v1/search?q=chittyassetsreturnedcount: 0. Service is NOT REGISTERED. Recommended registration payload (with all five P/L/T/E/A entity types declared) documented indocs/migrations/registry-status.md. Registration is a sensitive-intent operation gated onch1tty -> ChittyConnect— not executed by this PR.Compliance triad note
CHARTER.md,CHITTY.md,AGENTS.md,SECURITY.md, andregister.jsonland via PR #33 (feat/hono-migration-phase-1, commit806c8a5). Not duplicated here to avoid merge conflicts. After PR #33 merges, the triad should be cross-validated against this roadmap's canonical posture section.Test plan
chittycanon://URIs andserver/routes.ts:Nline citations resolveSummary by CodeRabbit