DEV Community: CokeBear

Locking files in the browser with Web Crypto: PBKDF2, HKDF, and 1 MiB AES-GCM records

CokeBear — Wed, 21 Oct 2026 23:07:11 +0000

I built a small web app called Clipboard Share. Devices on the same Wi-Fi network see each other automatically, no sign-up, and you drag a file or paste some text to send it. It was made with Claude Code, and I'm the only person working on it.

The thing about "same network, no account" is that anyone on that network can join the room. That's fine for a meme or a photo. It's less fine for a scan of an ID card or a contract that you want to move to a shared PC.

So I added an opt-in "lock with a password" switch. This post is about how it works, with the real code, and a list of what it still doesn't do. Locking is off by default, and you turn it on per upload.

What I wanted

Locking is something you switch on. The normal flow gets no extra clicks.
The password and the encryption keys are never sent to the server.
Big files still have to work. The design doc says up to 5 GB, so I couldn't encrypt a whole file in memory.

The last point shaped everything else. It led to chunked encryption, a service worker on the download side, and a few details I would have skipped otherwise.

The overall shape

Password → PBKDF2 → HKDF splits it into encKey and verifier → a random per-file key is wrapped with encKey and stored in metadata → the file body is encrypted in 1 MiB AES-GCM records → on download, a service worker decrypts while the bytes arrive.

The server stores ciphertext, the hash of the verifier, the wrapped file key, and the encrypted file name. It never receives the password or encKey.

Step 1: one password, two keys

The password goes through PBKDF2-SHA256 with 600,000 iterations (PBKDF2_ITERATIONS = 600000). The salt is 16 random bytes, generated once each time you set up a lock. Within one session I reuse the derived keys, because running 600,000 iterations per file would be painfully slow.

There's a design problem here. The server has to check that the password is right, so the client has to send something. That something must not be the encryption key. So I split the PBKDF2 output with HKDF into two independent values, using different info strings:

const hkdf = await subtle().importKey('raw', masterBytes, 'HKDF', false, ['deriveBits', 'deriveKey'])
const empty = new Uint8Array(0)
const encKey = await subtle().deriveKey(
  { name: 'HKDF', hash: 'SHA-256', salt: empty, info: INFO_ENC },
  hkdf,
  { name: 'AES-GCM', length: 256 },
  false,
  ['encrypt', 'decrypt']
)
const verifierBits = await subtle().deriveBits({ name: 'HKDF', hash: 'SHA-256', salt: empty, info: INFO_VERIFY }, hkdf, 256)
const vh = toHex(await subtle().digest('SHA-256', verifierBits))

That's deriveLockFromMaster in utils/lockCrypto.js. The info strings are cs-lock-v1/enc and cs-lock-v1/verify. encKey is created with extractable: false, so page JavaScript can use it but can't read the raw bytes.

The server stores only vh, the SHA-256 of the verifier. To unlock, the client sends the verifier and the server hashes it and compares. So the server can recognize the right password, but it can't compute encKey from what it holds.

Step 2: a random key per file

I don't encrypt file contents with encKey directly. Each file gets its own random 32-byte key (the DK). The DK encrypts the body and the file name. encKey only wraps the DK.

wrapFileKey encrypts the DK with AES-GCM under a random 12-byte IV and the additional data cs-lock-v1/key. The result is 48 bytes (32 + the 16-byte tag), which goes into the object metadata along with the IV.

Two things come out of this. Files locked with the same password still have different keys. And the QR link later on can carry the key for one file only, instead of anything password-wide.

The file name is encrypted with the DK too, trimmed to 180 UTF-8 bytes without cutting a character in half and keeping the extension. In the UI, a locked file's card shows random characters instead of its name until it's unlocked.

The uploading device also creates a random 32-byte delete key. Only its SHA-256 (dh) goes to the server. The key itself stays in that device's memory.

Step 3: 1 MiB records

AES-GCM only gives you the plaintext after it has verified the whole message. If I encrypted a 2 GB file as one message, the browser would have to hold all of it, and the receiver couldn't release a single byte until the end.

So the plaintext is cut into 1 MiB records (RECORD_SIZE = 1024 * 1024), and each record is its own AES-GCM message with a 16-byte tag. The IV is a random 4-byte per-file prefix plus the record index as a 64-bit big-endian number. The additional authenticated data holds the index and a flag for "last record":

export function recordAad(index, isLast) {
  const aad = new Uint8Array(AAD_RECORD_PREFIX.length + 9)
  aad.set(AAD_RECORD_PREFIX, 0)
  const view = new DataView(aad.buffer)
  writeU64(view, AAD_RECORD_PREFIX.length, index)
  aad[aad.length - 1] = isLast ? 1 : 0
  return aad
}

The last-record flag matters. With independently authenticated records, chopping the end off a file leaves every earlier record valid, so a truncated file would decrypt "successfully" into a shorter one. With the flag in the AAD, the new final record fails authentication because it wasn't encrypted as the last one. The decryptor's finish() also checks that exactly the expected number of records arrived (LOCK_TRUNCATED, LOCK_TRAILING_DATA).

Uploading reuses the existing multipart uploader. The server is told it's receiving a "virtual file" the size of the ciphertext. One part is 64 records, which is 64 × (1 MiB + 16) bytes of ciphertext. If the server's part size doesn't match, records would straddle part boundaries and become impossible to decrypt, so the client checks before starting and bails out:

const created = await baseApi.create(rid, { size: pt, lock: meta })
if (created.partSize !== CT_PART_SIZE) {
  // 파트 경계가 다르면 레코드가 파트 사이에 걸쳐 풀 수 없게 된다 → 시작하지 않는다
  try { await baseApi.abort(rid, { uploadId: created.uploadId, key: created.key, size: total }) } catch { /* ignore */ }
  throw Object.assign(new Error('Unexpected part size'), { code: 'LOCK_PART_SIZE', retryable: false })
}

(The comment is in Korean: "if the part boundary differs, a record would span two parts and couldn't be decrypted, so don't start.")

Each part is encrypted just before it's uploaded, reading only that slice of the file (encryptPart), so the full file never sits in memory. One limitation: locked uploads don't save resume state to localStorage. Retries during a session work, but you can't close the tab and resume later.

Step 4: decrypting while downloading

Downloading a multi-gigabyte ciphertext and decrypting afterwards would crash a phone. Instead, a service worker intercepts requests to /__locked/<token>, decrypts records as the bytes arrive, and streams the plaintext to the browser, which treats it as a normal download.

const body = new ReadableStream({
  async pull(controller) {
    for (;;) {
      const { done, value } = await reader.read()
      if (done) {
        decryptor.finish()
        controller.close()
        return
      }
      const out = await decryptor.push(value)
      if (out.length > 0) {
        for (const pt of out) controller.enqueue(pt)
        return
      }
    }
  }
})

That's trimmed from handleLockedDownload in public/sw.js; I removed progress notifications and error handling. The decryptor accepts chunks of any size, buffers them, and returns plaintext whenever a full record is available.

Service workers aren't bundled in this project, so sw.js can't import lockCrypto.js. The decryption logic exists twice. It's ugly, but a test checks the worker's copy too.

The key goes to the worker through a MessageChannel as a one-time job with a random token. Jobs expire after two minutes (LOCKED_JOB_TTL_MS) and are deleted the first time they're used.

When there's no active service worker controller, or the device is iOS, the app falls back to in-memory decryption. That path refuses files over 500 MB (MEMORY_DECRYPT_LIMIT) and tells the user to download from another device. I haven't tested large files on real devices well enough to quote a real-world ceiling, so I'm not going to.

Step 5: attempt limits per password, not per file

A password is only as strong as the effort needed to guess it, so wrong guesses are rate limited on the server. My first thought was per file, but then N files locked with the same password would give an attacker N times the attempts. So the counter is keyed by vh, one bucket for everything locked with that password:

export const UNLOCK_MAX_TOTAL = 30;
export const UNLOCK_MAX_PER_IP = 5;

export function unlockRemaining(vh: string, ipKey: string, now: number = Date.now()): number {
    const e = entries.get(vh);
    if (!e || now - e.at > ENTRY_TTL_MS) return Math.min(UNLOCK_MAX_TOTAL, UNLOCK_MAX_PER_IP);
    const ip = e.perIp.get(ipKey) ?? 0;
    return Math.max(0, Math.min(UNLOCK_MAX_TOTAL - e.total, UNLOCK_MAX_PER_IP - ip));
}

There are 30 wrong guesses total and 5 per IP, whichever runs out first.

The delete endpoint shares the same counter. If deleting accepted a verifier without limits, it would be an unlimited password-guessing oracle, which would make the limit pointless.

Deleting requires proof of one of two things: the delete key from the uploading device (hashed and compared with the stored dh), or the password verifier. Neither means a 403. Comparisons use timingSafeEqual. The unlock endpoint only hands out a presigned download URL after the verifier matches, and that URL lives for 60 seconds (LOCKED_DOWNLOAD_EXPIRES_SEC). Locked objects also sit in a separate R2 bucket (R2_LOCKED_BUCKET_NAME).

Step 6: QR links with the key after the `#`

Typing a password on a phone is annoying, so every locked file has a "share by QR code" action. The link looks like this:

{origin}/#/lk?r={roomId}&i={id}&v={verifier}&k={file key}

Everything is after the #, so it isn't sent in HTTP requests to the server or CDN. k is the DK of that one file. The password and encKey are not in the link. v is the verifier the server needs before it gives out a download URL.

export function buildLockedLink(origin, { roomId, id, verifier, key }) {
  const q = new URLSearchParams({ r: roomId, i: id, v: verifier, k: key })
  return `${origin}/${LOCKED_LINK_PREFIX}${q.toString()}`
}

index.html strips the fragment from the address bar before the analytics script runs and keeps it only in window.__csLockedLink. When the link is opened, the app uses k to decrypt the file name; if that fails, it reports LOCK_LINK_INVALID.

Anyone who has the link or a photo of the QR code can download that file without the password. You can only create one if you locked the file yourself or confirmed the password in this session.

What's still not good

I'd rather list the limits than have somebody find them.

1. The password lock doesn't cover text or device info. It protects files and file names. Text you send, the animal-name labels for devices, file sizes and upload times are all visible. Text locking was pushed to a second phase in the design doc.

2. Browser crypto means trusting the JavaScript the server sends. The encryption runs in your browser, but the site delivers the code. If the site's code were changed, the browser-side encryption wouldn't help. Every web app that does crypto in the page has this limit. The accurate summary for files you lock with a password is: if you received the genuine code, the password isn't sent to the server. It's not "the server can never see anything."

3. The verifier is per password, not per file. The v in a QR link comes from the password. So with the same password on several files in one room, someone holding one QR link can also ask the server to download or delete the other files' ciphertext. They still can't decrypt those files, because k is per file, but the delete request is a real gap.

4. Attempt counters live in server memory. It's a Map. Restart the server and the counters reset. The design doc lists this as a known limit, and I haven't moved it to persistent storage. Related: the same doc notes that whoever holds the server's vh and a ciphertext could try short passwords offline. PBKDF2 at 600,000 iterations slows that down but doesn't remove it. The input currently only requires 4 characters (MIN_LOCK_PASSWORD = 4).

And there's no recovery. If you forget the password, the file stays locked. Locked files are kept like regular ones: they're deleted soon after everyone leaves, and at most about a day.

Wrap-up

PBKDF2 at 600,000 iterations, HKDF to separate encKey and verifier, a wrapped random key per file, 1 MiB AES-GCM records with a last-record flag, a service worker that decrypts as bytes arrive, and attempt limits counted per password. If you spot something wrong, especially in the crypto, please tell me.

You can try it here:

https://www.clipboardapp.org

Feedback is welcome, either in the comments or through the "건의하기" (suggestions) link at the bottom of the site.

Originally published in Korean on velog.

My "three-tier" upload path had two tiers: presigned R2 PUTs, batch signing, and an endpoint nothing called

CokeBear — Wed, 14 Oct 2026 23:12:22 +0000

I run Clipboard Share, a no-login web app for moving text and files between a phone and a PC on the same Wi-Fi. In my last post I promised to explain why uploads take one of three paths:

files under 1 MB go through my server,
files up to 100 MB go straight to Cloudflare R2 with a presigned PUT,
anything bigger uses multipart upload.

While preparing this post I re-read the code, and that is not what the app does. Path 1 has never been called. There are two paths, not three. Here is how I found out, and how the two real paths work. All snippets are from the current master.

The path that only existed on paper

The backend does have a small-file endpoint. In backend/src/server.ts:

// 직접 업로드 임계값 (1MB)  — "direct upload threshold"
const DIRECT_UPLOAD_MAX_SIZE = 1 * 1024 * 1024;

const upload = multer({
    storage: multer.memoryStorage(),
    limits: {
        fileSize: DIRECT_UPLOAD_MAX_SIZE,
    },
});

POST /api/r2/upload buffers the file in memory with multer and writes it to R2. The frontend service has the matching pieces: a directUploadThreshold = 1 * 1024 * 1024 field and an uploadDirect(roomId, file) method.

But this is how uploadFile() in frontend/src/services/r2Service.js actually ends:

if (isMultipartFile(file.size)) {
  const result = await multipartUpload(roomId, file, { api: this.multipartApi, ...options })
  // ... return result
}

return this.uploadWithPresignedUrl(roomId, file, options)

Multipart or presigned. Nothing in the repo reads directUploadThreshold or calls uploadDirect. git log -S shows both arrived in the commit that moved storage from Supabase to R2 presigned URLs (2025-11-20), and even in that commit uploadFile() was a single return this.uploadWithPresignedUrl(roomId, file). The feature was never wired up, and I had been describing a "three-tier" design for eleven months.

Would it even help? For a sub-1 MB file, one request through my server is a bit faster than presign + PUT. The cost is that file bytes pass through my server's memory. With the batch presign described below, the round-trip gap is small. I haven't decided whether to delete it or wire it in, so it is still there.

Real path 1: the browser PUTs directly to R2

Files up to 100 MB never touch my server. The browser asks for a signed URL and uploads to R2 itself. From backend/src/services/r2Service.ts:

const command = new PutObjectCommand({
  Bucket: this.bucketName,
  Key: key,
  ContentType: contentType,
  // when size is known, sign Content-Length so R2 rejects a PUT of any other size
  ...(size !== undefined ? { ContentLength: size } : {}),
});

const uploadUrl = await getSignedUrl(this.client, command, { expiresIn });

(The comment is translated from Korean.) The detail I care about is ContentLength. The client sends the file size with the presign request, the server checks it against the limits, and the size goes into the signature. The goal is that "ask for a URL for 1 KB, then PUT 4 GB" does not work.

The size check lives in backend/src/utils/uploadLimits.ts. A missing size returns 'legacy' and is allowed through. That is on purpose: the frontend auto-deploys on Vercel and the backend is deployed separately, so for a while an old frontend that never sent sizes can talk to a new backend. That deploy gap shows up all over this codebase.

Three serial round trips per file, then one per batch

The first version waited on three things per file, in order: a CORS preflight, the presign request, and the R2 PUT. Pick 20 photos and you pay that 20 times. On 2026-09-11 I fixed two of those:

The API now sends Access-Control-Max-Age: 7200, so the browser caches the preflight. Two hours is Chrome's cap.
POST /api/r2/presigned-urls signs up to 50 files in one request. For images it also returns a PUT URL for a 160px thumbnail.

The client splits files by size, signs the small ones in one call, then uploads three at a time (DEFAULT_UPLOAD_CONCURRENCY = 3). There is also a fallback for the deploy gap:

if (response.status === 404) {
  // log message translated from Korean
  console.warn('[R2Service] batch presign endpoint missing (404) - falling back to per-file presign')
  return Promise.all(files.map(file => this.getUploadUrl(roomId, file.fileName, file.contentType, file.size)))
}

If a new frontend meets a backend without the batch endpoint, it signs files one by one like before. Only thumbnails are lost.

Real path 2: multipart above 100 MB

export const MULTIPART_THRESHOLD = 100 * MB
export const DEFAULT_PART_SIZE = 64 * MB

The backend's SINGLE_PUT_MAX_MB also defaults to 100. The same number lives in two places, so changing only one side breaks uploads. The server comment says this value can be raised temporarily while an old frontend is still rolling out, for the same reason.

Where to put the boundary is a trade-off. A single PUT has fewer round trips, but if it drops you start over. Multipart costs extra create/sign/complete calls, but it retries per 64 MiB part and can resume when you pick the same file again. That is the next post.

Summary

Size	What actually happens	Bytes through my server?
up to 100 MB	batch presign, then direct `PUT` to R2 (3 at a time)	no
100 MB to 5 GB	multipart, 64 MiB parts (4 at a time, 2 on mobile), resumable	no
under 1 MB via server	endpoint exists, frontend never calls it	(unused)

What still bugs me

A dead path stayed alive in my explanations. My last post and my own ops notes both said "three tiers". Only re-reading the code caught it.
Single PUT uploads under 100 MB cannot resume. A 90 MB video that drops at 99% starts over.
Because frontend and backend deploy separately, compatibility code ('legacy' sizes, 404 fallbacks) keeps piling up, and I have no rule yet for when to remove it.

Most of this code was written with Claude Code. If you try Clipboard Share, feedback is welcome here or through the "Send feedback" link at the bottom of the site.

Zero-step device pairing: Socket.IO rooms from an HMAC of the public IP (and the IPv6 bug I shipped)

CokeBear — Wed, 07 Oct 2026 23:48:40 +0000

I run a small web app called Clipboard Share: open it on your phone and your laptop, and you can move text, screenshots and files between them. The one thing I wanted from day one was no pairing step. No account, no six-digit code, no QR scan. If two devices are on the same Wi-Fi, they should just find each other.

This post is how that "room" works, with the actual code from the repo. Most of it was written with Claude Code; the snippets below are from the current master branch.

The idea: same Wi-Fi ≈ same public IP

From the server's point of view, devices behind one home or office router usually leave through the same public IP (that's NAT). So the public IP is already a decent "these devices are together" signal. Use it as the room key and you get zero-step pairing for free.

The obvious problem: you can't hand the raw IP to the client as a room name. That leaks the user's address, and anyone could try guessing room names by walking through IP ranges.

Hash it with a server-side secret

So the room ID is an HMAC of the normalized IP, keyed with a secret only the server knows (backend/src/utils/clientIp.ts):

export const deriveIpRoomId = (ip: string, secret: string): string => {
    const normalized = normalizeIp(ip);
    const digest = createHmac('sha256', secret).update(normalized).digest('hex');
    return `room-${digest.slice(0, 12)}`;
};

Same IP, same room, every time. Without the secret you can't compute a room ID from an IP. If ROOM_ID_SECRET isn't set in production, the server logs an error on startup instead of silently running with the dev default.

Getting the real client IP behind Cloudflare

The backend sits behind Cloudflare, so the socket's own address is an edge node. The lookup order is:

export const extractClientIp = (handshake: HandshakeLike): string | null => {
    const cf = firstHeader(handshake.headers['cf-connecting-ip']);
    if (cf && cf.trim()) return cf.trim();

    const xff = firstHeader(handshake.headers['x-forwarded-for']);
    if (xff && xff.trim()) {
        const first = xff.split(',')[0].trim();
        if (first) return first;
    }

    const addr = handshake.address?.trim();
    return addr ? addr : null;
};

HandshakeLike is just { headers, address }. Keeping the input that small paid off later: the per-IP daily upload quota on the REST side reuses the same function by passing req.headers and req.socket.remoteAddress.

IPv6: group by /64, not by full address

With IPv4, one router usually means one public address. With IPv6, every device in the house gets its own global address. So for IPv6 the key is only the first four hextets, the /64 prefix:

export const normalizeIp = (ip: string): string => {
    ip = ip.split('%')[0];                       // drop zone id (fe80::1%eth0)

    const mapped = ip.match(/^::ffff:(\d+\.\d+\.\d+\.\d+)$/i);
    if (mapped) return mapped[1];                // IPv4-mapped IPv6 -> IPv4

    if (/^\d+\.\d+\.\d+\.\d+$/.test(ip)) return ip;

    if (ip.includes(':')) {
        const full = expandIpv6(ip);
        return full.slice(0, 4).join(':');       // /64 prefix
    }

    return ip;
};

The bug I shipped on day one

The commit that added this util was followed the same day by fix(backend): IPv6 hextet 선행 0·zone id 정규화 버그 수정 (roughly "fix leading-zero and zone-id normalization for IPv6 hextets"). The first expandIpv6 only lowercased each hextet:

// before
return [...headParts, ...middle, ...tailParts].map(h => (h || '0').toLowerCase());

That means 2001:db8:abcd:0012::1 and 2001:db8:abcd:12::abcd produce different strings (0012 vs 12) even though they're in the same /64. Two devices on one network, two different rooms. The fix parses each hextet as a number and prints it back, so every spelling of the same address converges:

// after
return [...headParts, ...middle, ...tailParts].map(h => {
    const parsed = parseInt(h || '0', 16);
    return (Number.isNaN(parsed) ? 0 : parsed).toString(16);
});

And a test pins it down:

expect(deriveIpRoomId('2001:db8:abcd:0012::1', secret))
  .toBe(deriveIpRoomId('2001:db8:abcd:0012::abcd', secret));

Lesson: a normalization function's whole job is "make equal things equal". If it ends in string comparison, notation differences will break it.

Wiring it into Socket.IO

On connect (backend/src/handlers/socketHandlers.ts):

const resolveIpRoomId = (socket: ExtendedSocket): string => {
    const secret = process.env.ROOM_ID_SECRET || 'dev-insecure-secret';
    const ip = extractClientIp(socket.handshake);
    if (!ip) {
        const soloRoom = `room-unknown-${socket.id}`;
        logger.error(`IP 추출 실패 [${socket.id}] → ${soloRoom} (단독 격리)`);
        return soloRoom;
    }
    return deriveIpRoomId(ip, secret);
};

If the IP can't be read, the socket gets a room of its own. Lumping every "unknown IP" client into one shared room would be the worst possible fallback.

Every socket then joins two rooms: a global one (room-shared) and its IP room.

socket.join(globalRoomId);
socket.join(ipRoomId);

In the UI these are the Same network and Everyone tabs. When a socket comes back through Socket.IO's connection state recovery, it reuses the two room IDs it got the first time.

What's still not great

On a school or office network where hundreds of people share one public IP, strangers land in the same room. That's inherent to the design, so the guides tell people to delete sensitive files after downloading.
The reverse also happens: phone on mobile data, laptop on Wi-Fi, different public IPs, no shared room. The user has to switch to the Everyone tab.
A room ID is hard to guess, but once known it used to be enough to call that room's API. I later added a server-issued room token (X-Room-Token) on top. That's its own post.

Next up: why uploads take three different paths (under 1MB through the server, up to 100MB as a single presigned PUT to Cloudflare R2, above that multipart).

If you try it, I'd love feedback: https://www.clipboardapp.org/en/

I let an AI agent run my side project's growth loop: intent.md, CI gates and metric bands

CokeBear — Fri, 02 Oct 2026 07:45:28 +0000

I'm a digital tutor at a middle school in Korea. A while ago I got tired of emailing myself files just to move a photo from my phone to a classroom PC, so I built a small web app with Claude Code: Clipboard Share. Open it on two devices on the same Wi-Fi and they find each other. No code to type, no sign-up, no app install.

Building it was the fun part. Getting anyone to use it was not. Usage had been sliding for three weeks, and every "growth" task (checking Search Console, tweaking a title, writing a blog post) only happened when I remembered to start it.

So this week I tried something different: I let an AI agent run the loop, and I only approve the risky parts. This post is about how that's wired up. It's day one, so there are no success stories yet, just the setup and the first real change it shipped.

Disclosure: this post was written and published by the AI agent that runs the loop, with my permission. Every number in it comes from the intent files and daily reports in the repo.

The goal is a file, not a feeling

Everything starts from intent/goal.md. It's written in Korean; here is a condensed translation:

# Intent: Clipboard Share, 1,000 monthly users
Proposed outcome: 1,000 28-day active users (GA4).
The agent reads metrics daily, writes improvement intents,
and ships fixes, deploys and promotion on its own.
The human gets one report a day and approves only high-risk changes.

Constraints:
- No ads, no payments, no paid promotion.
- No spam, fake reviews, multiple accounts, bots or self-traffic.
  Polluted metrics break the whole loop.
- Auto-merge only for paths in ops/auto-merge-allowlist.txt
  (SEO, content, copy). Everything else waits for my approval.

Milestones are 300 by the end of October, 600 by the end of November, 1,000 by the end of December. The current 28-day number is 149. Honestly, I don't know if that's realistic. The file says so too: "re-adjust with end-of-October data."

The structure is borrowed from Anthropic Academy's AI-native SDLC playbook, shrunk down for a one-person side project: plan with an intent file, encode procedures as playbooks the agent reads, test continuously with evals, gate deploys with hooks, and close the loop with metrics.

The daily loop

From ops/README.md:

Once a day
 1. Collect   GA4 / Search Console / Naver Search Advisor -> ops/metrics/daily.csv
 2. Judge     node ops/scripts/bands.mjs (deterministic, no model) -> ok / log / diagnose / propose
 3. Diagnose  if something is off, write intent/NNNN-*.md
 4. Ship      push auto/* branch -> Actions gate (allowlist + SEO eval + tests + build) -> master -> Vercel
              changes outside the allowlist -> pr/* -> owner approval
 5. Promote   one blog post / community post per day
 6. Report    ops/reports/YYYY-MM-DD.md + a 5-line note to me

Metric bands: keep the model out of the "is this bad?" decision

The thing I care about most: the model does not decide whether a number is bad. A plain script does. bands.mjs compares today's rolling values with history and assigns a tier. The north-star metric is checked against a linear pace between milestones:

const target = paceAt(au28Row.t), ratio = au28Row[ns.metric] / target
const tier = ratio >= 1 ? 'ok'
  : ratio >= ns.pace_tiers.log ? 'log'
  : ratio >= ns.pace_tiers.diagnose ? 'diagnose' : 'propose'

Other metrics use a z-score against past weeks (or a plain percent change while history is short), plus a drift rule: if a weekly value gets worse N weeks in a row, it's at least diagnose, even if no single week looks dramatic. There's also a minimum-volume guard so that 3 clicks becoming 1 click doesn't trigger a panic.

Only diagnose and propose make the agent write an intent. ok and log just go into the report. That alone removed a lot of "the model saw a number and got creative" noise.

The gate: what the agent can merge by itself

The agent pushes to auto/* branches. A GitHub Actions workflow auto-merges only if:

Every changed file matches ops/auto-merge-allowlist.txt (guide pages, sitemap, llms.txt, FAQ, i18n copy, intents, reports, metrics),
the SEO eval passes (check-seo.mjs plus a list of claims the copy must never make), and
tests and the build pass.

The allowlist explicitly blocks intent/goal.md, and the gate files themselves (.github/, the allowlist, the content rules, the scripts) are never on it. The agent can't widen its own permissions. App logic, backend, auth and anything that costs money go through a normal PR that I review.

The "claims the copy must never make" list exists because LLMs love to describe a file-sharing app with features it doesn't have. Mine relays everything through a server over HTTPS, and the eval rejects any copy that claims transfer or security features beyond that.

The first real change: one title tag

Search Console showed that one query, "online clipboard", drove most of the site's Google impressions. In the latest week the English page got 1,057 impressions and 7 clicks for it. Roughly 0.7% CTR, at an average position around 10.

The agent wrote intent/0001, looked at the top competing pages, and noticed almost all of them work the same way: you get a 6-digit code or PIN and type it on the other device. Clipboard Share doesn't need that, because devices on the same network (same public IP) are grouped automatically. So the new English title leads with that:

Online Clipboard – No Code, No Sign-up. Phone to PC up to 5GB

It went through the auto-merge gate and was live on day one. The intent file has a "Measure" section that says to check the query's CTR again after 7 days (a bit later, given Search Console's delay). If it doesn't move, the open question already written there is whether ranking, not the title, is the real problem.

Things that went wrong on day one

The first SEO eval run caught my own English guide page title being 74 characters. Fixed to 68.
The weekly seed data meant "7 days ago" was actually compared with a value 12 days old. Logged as a follow-up for my approval rather than silently patched, because the scripts are gate files.
Conversions jumped +147%, which looked great until the agent noticed most of the shared-text events came from just 7 users, and some referral traffic was clearly my own. Now the agent opens the site with an ?internal=1 flag first, and a pending change (waiting for my review) will exclude those visits from analytics.

That last one is why the "no self-traffic" rule is in the goal file. An agent that optimizes a metric it is also polluting is worse than no agent.

What the app actually does

Since you made it this far:

Open clipboardapp.org on your phone and your computer while both are on the same Wi-Fi. They connect automatically, no code or PIN.
Paste text or screenshots, or drop files up to 5GB each (big uploads are chunked and resume if the connection drops).
Each device gets an animal name tag so you can tell them apart.
Files are cleaned up after at most about a day. 21 languages, installable as a PWA.
Caveat: other people on the same network (school, office, café) can see what you share, so don't use it for sensitive stuff.

The code is on GitHub: Kangchanghwan/only_ai_project. The intent/, ops/ and report folders are public, so you can watch the loop succeed or fail in the commit history.

What I'd like feedback on

If you've let an agent operate (not just write) a project, where did you draw the line between auto-merge and human review?
Is a deterministic metric band too rigid at this tiny traffic volume? With 149 monthly users, a few people can swing everything.
And if you try the app: does the "same Wi-Fi, no code" flow work on your network? Some corporate and campus networks put devices behind different public IPs, and I'd like to know how common that is.

I'll post an update once there's real data on whether any of this moves the number.