Skip to content

Commit 63fe5a0

Browse files
prdaiclaude
prdai
and
claude
authored
Cloudflare KV cache adapter for Drizzle ORM + docs site (#1)
* feat: Cloudflare KV cache adapter for Drizzle ORM + docs site Add drizzle-cloudflare-kv-cache-adapter: a Cloudflare KV-backed implementation of Drizzle ORM's query cache interface for Workers/D1. - Adapter (src/index.ts): cloudflareKVCache() factory + CloudflareKVCache class. Per-table reverse index for invalidation, TTL clamping to KV's 60s minimum, explicit/all strategies, configurable key prefix. - Tests (bun test): 14 cases over an in-memory KV mock. - Build: ESM-only via tsup with .d.ts; peer dep drizzle-orm >=0.44. - CI: typecheck + test + build on PR; npm publish on tag. - Docs: Astro + Starlight site (black & white theme), deployed as a static-assets Cloudflare Worker at drizzle-kv-cache.bbyb.dev. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat(docs): hero code panel, top nav, favicon, theme polish - Add copyable worker.ts snippet in the splash hero (image slot) with syntax-colored tokens and a copy button. - Custom Header override: top nav links (Start here / Guides / Reference) with a sidebar-independent flex layout so the search box no longer shifts between the splash and doc pages. - Add SVG favicon. - Bigger, airier sidebar typography; remove the redundant code block at the bottom of the home page. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * chore: add Biome, Lefthook, and agent rules - Biome 2.x for lint/format (single quotes, no semicolons, 2-space). - Lefthook hooks: pre-commit runs biome on staged files; pre-push runs typecheck + test + build. - Add CLAUDE.md / AGENTS.md (agentic engineering rules). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix: tag-based invalidation + px TTL; resolve PR review Addresses review feedback on PR #1: - onMutate now handles params.tags as well as params.tables. Tagged queries (.$withCache({ tag })) are stored under {prefix}:t:{tag} and invalidated directly via invalidate({ tags }); the per-table reverse index now stores full storage keys so table invalidation also drops tagged entries. (src/index.ts:96) - put() resolves TTL from px (ms) in addition to ex (s). - README: add wrangler.jsonc binding variant and the 'wrangler kv namespace create CACHE' command. (README.md:30) - Docs: document tagged queries + tag invalidation + px in usage, invalidation, and API reference. - Redesign favicon (Cloudflare cloud + Drizzle slashes + KV cell). - Bigger hero code panel. - Migrate biome config to rules.preset. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: prdai <prdai@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1 parent 466d232 commit 63fe5a0

33 files changed

Lines changed: 3369 additions & 0 deletions

‎.github/workflows/ci.yml‎

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
name: CI
2+
3+
on:
4+
push:
5+
branches: [main]
6+
pull_request:
7+
branches: [main]
8+
9+
jobs:
10+
build:
11+
runs-on: ubuntu-latest
12+
steps:
13+
- uses: actions/checkout@v4
14+
- uses: oven-sh/setup-bun@v2
15+
with:
16+
bun-version: latest
17+
- run: bun install --frozen-lockfile
18+
- run: bun run typecheck
19+
- run: bun test
20+
- run: bun run build

‎.github/workflows/release.yml‎

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
name: Release
2+
3+
on:
4+
push:
5+
tags:
6+
- 'v*'
7+
8+
jobs:
9+
publish:
10+
runs-on: ubuntu-latest
11+
permissions:
12+
contents: read
13+
id-token: write
14+
steps:
15+
- uses: actions/checkout@v4
16+
- uses: oven-sh/setup-bun@v2
17+
with:
18+
bun-version: latest
19+
- uses: actions/setup-node@v4
20+
with:
21+
node-version: 20
22+
registry-url: 'https://registry.npmjs.org'
23+
- run: bun install --frozen-lockfile
24+
- run: bun run typecheck
25+
- run: bun test
26+
- run: bun run build
27+
- run: npm publish --provenance --access public
28+
env:
29+
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

‎AGENTS.md‎

Lines changed: 120 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,120 @@
1+
# Agentic Engineering Rules
2+
3+
This project is run as agentic engineering, not vibe coding.
4+
5+
The human user is the technical lead. The agent is a supporting engineer that
6+
helps generate, inspect, explain, and verify code under the lead's direction.
7+
Treat the workflow as pair programming between two engineers, with the user
8+
driving scope and decisions.
9+
10+
## Operating Rules
11+
12+
- Follow the user's requested scope exactly.
13+
- Do not expand the task into broad implementation work unless the user asks
14+
for that broader scope.
15+
- Do not perform massive, open-ended changes just because they seem useful.
16+
- Do not defy explicit user instructions.
17+
- If the user says not to edit, commit, push, delete, refactor, or implement
18+
something, do not do it.
19+
- Preserve existing work unless the user explicitly asks for destructive
20+
cleanup.
21+
- Prefer small, reviewable changes over large rewrites.
22+
- Communicate what you are doing before making edits.
23+
- Explain why actions are being taken, not only what changed. The user should
24+
be able to understand the reasoning behind commands, edits, architecture
25+
choices, validation steps, and tradeoffs.
26+
- When reporting work, connect each meaningful change to the reason it was
27+
needed and the effect it has on the project.
28+
- When the task is ambiguous, ask or make the smallest reasonable assumption
29+
and state it clearly.
30+
31+
## Branch and PR Workflow
32+
33+
Work should happen through normal feature branches and pull requests.
34+
35+
- Start new implementation work from an up-to-date `main` unless the user says
36+
otherwise.
37+
- Before starting a new feature, check out `main`, pull the latest remote state,
38+
then create a focused feature branch.
39+
- Use small branches for coherent units of work.
40+
- After the user merges a PR, return to `main`, pull the latest changes, then
41+
create the next feature branch from that updated base.
42+
- Do not continue stacking unrelated work on an old feature branch unless the
43+
user explicitly asks for stacked PRs.
44+
- Keep PRs small and reviewable. The PR should describe the important behavior
45+
change, verification performed, and any known review or test gaps.
46+
47+
## Conversation History
48+
49+
Agent conversations should be exportable when the tool supports it so the work
50+
stays transparent and reviewable.
51+
52+
- Keep tool-specific conversation exports in tool-specific directories, such as
53+
`.codex/` for Codex sessions and `.claude/` for Claude sessions.
54+
- Export or update conversation history at practical workflow checkpoints,
55+
especially before creating a commit, before opening a PR, after addressing
56+
review feedback, and when switching tools or agents.
57+
- Do not rely on continuous every-message export unless the tool supports it
58+
cleanly. Use checkpoint exports so the history stays useful instead of noisy.
59+
- Use these exports to preserve what the user asked for, what the agent did,
60+
why the agent did it, what assumptions were made, and what verification was
61+
performed.
62+
- Do not treat chat history as a substitute for clear commits, PR descriptions,
63+
tests, or documentation.
64+
- Do not commit private credentials, secrets, tokens, or sensitive local machine
65+
details in exported chat history.
66+
- If an export contains sensitive data, redact it before committing or ask the
67+
user how to handle it.
68+
- Prefer small, dated, tool-specific transcript files over one large opaque
69+
history dump.
70+
71+
## Commit Discipline
72+
73+
Commits are part of the collaboration loop.
74+
75+
- Do not commit initial agent changes automatically unless the user asks for a
76+
commit.
77+
- After the user reviews the current work and asks for changes, apply only that
78+
requested change, verify it, then make a focused follow-up commit if commits
79+
are in scope.
80+
- If the user asks for another change after that, make another focused commit
81+
for that change.
82+
- Do not squash or rewrite history unless the user explicitly asks.
83+
- Do not stage or commit unrelated files.
84+
- If the user says `do not commit`, do not commit.
85+
- If review was limited or the agent thinks the user has not reviewed enough,
86+
say so clearly before committing and note the review gap in the commit body.
87+
- If the user has properly reviewed the change, record that in the commit body
88+
with a trailer such as `Signed-off-by: User`.
89+
- If review was incomplete, use a clear note such as
90+
`Review: Limited user review before commit`.
91+
- When an agent or tool contributes to a commit, include it in the commit
92+
trailers with `Co-authored-by`, using the correct tool identity for the agent
93+
used at that time. For example, Codex-authored work should include a Codex
94+
`Co-authored-by` trailer.
95+
- Preserve user-requested trailers such as `Signed-off-by` when the user asks
96+
for them.
97+
98+
## Fact Checking
99+
100+
The agent must fact check the user's assumptions when needed. That means:
101+
102+
- Point out incorrect technical claims.
103+
- Surface missing constraints, especially AWS Nitro Enclaves constraints.
104+
- Explain risks and tradeoffs clearly.
105+
- Distinguish verified facts from assumptions.
106+
- Explain the reasoning behind corrections so the user can judge the technical
107+
basis, not just receive a blunt contradiction.
108+
109+
Fact checking is discussion. It does not give the agent permission to ignore
110+
the user's instructions or perform extra work outside the requested scope.
111+
112+
## Engineering Bar
113+
114+
- Be direct, factual, and technically rigorous.
115+
- Read the code and docs before making claims about the system.
116+
- Prefer repo-native tooling and existing patterns.
117+
- Verify meaningful behavior with commands or tests when possible.
118+
- Report exactly what was changed and what was not verified.
119+
- Include the reason behind important implementation choices, especially when
120+
choosing a cheaper, simpler, safer, or more repo-native path.

‎CLAUDE.md‎

Lines changed: 120 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,120 @@
1+
# Agentic Engineering Rules
2+
3+
This project is run as agentic engineering, not vibe coding.
4+
5+
The human user is the technical lead. The agent is a supporting engineer that
6+
helps generate, inspect, explain, and verify code under the lead's direction.
7+
Treat the workflow as pair programming between two engineers, with the user
8+
driving scope and decisions.
9+
10+
## Operating Rules
11+
12+
- Follow the user's requested scope exactly.
13+
- Do not expand the task into broad implementation work unless the user asks
14+
for that broader scope.
15+
- Do not perform massive, open-ended changes just because they seem useful.
16+
- Do not defy explicit user instructions.
17+
- If the user says not to edit, commit, push, delete, refactor, or implement
18+
something, do not do it.
19+
- Preserve existing work unless the user explicitly asks for destructive
20+
cleanup.
21+
- Prefer small, reviewable changes over large rewrites.
22+
- Communicate what you are doing before making edits.
23+
- Explain why actions are being taken, not only what changed. The user should
24+
be able to understand the reasoning behind commands, edits, architecture
25+
choices, validation steps, and tradeoffs.
26+
- When reporting work, connect each meaningful change to the reason it was
27+
needed and the effect it has on the project.
28+
- When the task is ambiguous, ask or make the smallest reasonable assumption
29+
and state it clearly.
30+
31+
## Branch and PR Workflow
32+
33+
Work should happen through normal feature branches and pull requests.
34+
35+
- Start new implementation work from an up-to-date `main` unless the user says
36+
otherwise.
37+
- Before starting a new feature, check out `main`, pull the latest remote state,
38+
then create a focused feature branch.
39+
- Use small branches for coherent units of work.
40+
- After the user merges a PR, return to `main`, pull the latest changes, then
41+
create the next feature branch from that updated base.
42+
- Do not continue stacking unrelated work on an old feature branch unless the
43+
user explicitly asks for stacked PRs.
44+
- Keep PRs small and reviewable. The PR should describe the important behavior
45+
change, verification performed, and any known review or test gaps.
46+
47+
## Conversation History
48+
49+
Agent conversations should be exportable when the tool supports it so the work
50+
stays transparent and reviewable.
51+
52+
- Keep tool-specific conversation exports in tool-specific directories, such as
53+
`.codex/` for Codex sessions and `.claude/` for Claude sessions.
54+
- Export or update conversation history at practical workflow checkpoints,
55+
especially before creating a commit, before opening a PR, after addressing
56+
review feedback, and when switching tools or agents.
57+
- Do not rely on continuous every-message export unless the tool supports it
58+
cleanly. Use checkpoint exports so the history stays useful instead of noisy.
59+
- Use these exports to preserve what the user asked for, what the agent did,
60+
why the agent did it, what assumptions were made, and what verification was
61+
performed.
62+
- Do not treat chat history as a substitute for clear commits, PR descriptions,
63+
tests, or documentation.
64+
- Do not commit private credentials, secrets, tokens, or sensitive local machine
65+
details in exported chat history.
66+
- If an export contains sensitive data, redact it before committing or ask the
67+
user how to handle it.
68+
- Prefer small, dated, tool-specific transcript files over one large opaque
69+
history dump.
70+
71+
## Commit Discipline
72+
73+
Commits are part of the collaboration loop.
74+
75+
- Do not commit initial agent changes automatically unless the user asks for a
76+
commit.
77+
- After the user reviews the current work and asks for changes, apply only that
78+
requested change, verify it, then make a focused follow-up commit if commits
79+
are in scope.
80+
- If the user asks for another change after that, make another focused commit
81+
for that change.
82+
- Do not squash or rewrite history unless the user explicitly asks.
83+
- Do not stage or commit unrelated files.
84+
- If the user says `do not commit`, do not commit.
85+
- If review was limited or the agent thinks the user has not reviewed enough,
86+
say so clearly before committing and note the review gap in the commit body.
87+
- If the user has properly reviewed the change, record that in the commit body
88+
with a trailer such as `Signed-off-by: User`.
89+
- If review was incomplete, use a clear note such as
90+
`Review: Limited user review before commit`.
91+
- When an agent or tool contributes to a commit, include it in the commit
92+
trailers with `Co-authored-by`, using the correct tool identity for the agent
93+
used at that time. For example, Codex-authored work should include a Codex
94+
`Co-authored-by` trailer.
95+
- Preserve user-requested trailers such as `Signed-off-by` when the user asks
96+
for them.
97+
98+
## Fact Checking
99+
100+
The agent must fact check the user's assumptions when needed. That means:
101+
102+
- Point out incorrect technical claims.
103+
- Surface missing constraints, especially AWS Nitro Enclaves constraints.
104+
- Explain risks and tradeoffs clearly.
105+
- Distinguish verified facts from assumptions.
106+
- Explain the reasoning behind corrections so the user can judge the technical
107+
basis, not just receive a blunt contradiction.
108+
109+
Fact checking is discussion. It does not give the agent permission to ignore
110+
the user's instructions or perform extra work outside the requested scope.
111+
112+
## Engineering Bar
113+
114+
- Be direct, factual, and technically rigorous.
115+
- Read the code and docs before making claims about the system.
116+
- Prefer repo-native tooling and existing patterns.
117+
- Verify meaningful behavior with commands or tests when possible.
118+
- Report exactly what was changed and what was not verified.
119+
- Include the reason behind important implementation choices, especially when
120+
choosing a cheaper, simpler, safer, or more repo-native path.

‎LICENSE‎

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
MIT License
2+
3+
Copyright (c) 2026 BitByBit-B3
4+
5+
Permission is hereby granted, free of charge, to any person obtaining a copy
6+
of this software and associated documentation files (the "Software"), to deal
7+
in the Software without restriction, including without limitation the rights
8+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9+
copies of the Software, and to permit persons to whom the Software is
10+
furnished to do so, subject to the following conditions:
11+
12+
The above copyright notice and this permission notice shall be included in all
13+
copies or substantial portions of the Software.
14+
15+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21+
SOFTWARE.

0 commit comments

Comments
 (0)