DEV Community: kongkong

"Carry Actor Provenance From Linear UI to Worker"

kongkong — Wed, 29 Jul 2026 09:46:59 +0000

A Linear button says “delegate,” the API creates a job, and the worker sees only task_id. Identity disappeared between layers. The worker now cannot distinguish the initiating human, integration, tenant, or approved scope.

What the announcement establishes

GitHub announced Copilot cloud agent for Linear as generally available on July 23, 2026. Delegation from Linear creates a cross-system path; the implementation below is an independent application pattern, not a description of GitHub internals. Read the primary source.

For test track 5.1, the engineering claim here is narrower than the announcement: the surrounding workflow needs a contract that remains valid when metadata, transport, people, or executors change.

The artifact

type Provenance = {
  actorId: string; tenantId: string; source: "linear";
  issueId: string; scope: string[]; issuedAt: string;
  expiresAt: string; nonce: string;
};
type Job = { kind: "apply_patch"; provenance: Provenance; headSha: string };

Middleware should authenticate the inbound integration, resolve its tenant mapping, overwrite rather than trust client-supplied actor fields, authorize scope, and sign the canonical envelope before enqueueing.

For test track 5.2, this is a design fixture, not executed code. Pin language and dependency versions before turning it into a repository test, and replace example identities and timestamps with disposable values.

Success path

The UI displays the resolved actor and scope. The API persists the signed envelope, and the worker verifies signature, expiry, tenant, nonce, head SHA, and path authorization before applying anything.

For test track 5.3, a successful demonstration records inputs, policy or schema version, decision, and final identifier. It does not infer correctness from a confidence label, status badge, or fluent output.

Failure path and regression plan

A replayed nonce, stale SHA, altered scope, or mismatched tenant moves the job to a denied terminal state. It must not be retried as a transient worker error.

Cover UI payload tampering, API actor overwrite, schema-version rejection, queue serialization, expired authorization, duplicate nonce, worker crash after apply, and rollback authorization.

For test track 5.4, the acceptance gate is binary: the negative fixture must produce no unauthorized or duplicate side effect, while the positive fixture must remain traceable to its initial evidence. Expected output should be documented before execution.

Cleanup and rollback

Pause consumers, reject new delegation, reconcile jobs by nonce, revert only commits tied to valid provenance, and rotate the signing key if envelope integrity is uncertain.

For test track 5.5, cleanup must preserve enough sanitized evidence to distinguish cancellation, rejection, stale work, and successful completion. Never solve recovery by silently marking an uncertain operation successful.

Limitations

For test track 5.6, this article proposes a compact engineering exercise and reports no execution results. It does not evaluate service availability, security, accessibility conformance, productivity, or comparative quality. Product previews can change, and a local fixture cannot reproduce every hosted-system failure.

A practical development environment

For unrelated implementation work, MonkeyCode is an open-source AGPL-3.0 AI development platform with an overseas hosted option. It includes a managed server-side cloud development environment, integrated models, task and requirement management, and build, test, and preview workflows. It is free to start. These statements do not mean the GitHub or OpenAI capability discussed above exists in MonkeyCode. Check the console for current quotas, models, regions, duration, and pricing before planning work. Open the campaign workspace.

Disclosure: This article promotes MonkeyCode using an official campaign link. I’m a MonkeyCode user, not affiliated with the project, and I receive no commission from this link.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited primary sources.

"Give Every Preview URL a Lifecycle Contract From Build to Expiry"

kongkong — Tue, 28 Jul 2026 03:41:09 +0000

A build can succeed while its preview URL points to yesterday’s artifact. The browser sees a page, the API says “ready,” and nobody can prove which commit is being reviewed. Fix that handoff with a preview resource whose identity includes the build and whose expiry is explicit.

This is a proposed vertical-slice contract, not a description of MonkeyCode internals.

{
  "preview_id": "prv_01",
  "workspace_id": "ws_01",
  "build_id": "bld_01",
  "commit_sha": "40-hex-replace-me",
  "state": "PROVISIONING",
  "url": null,
  "created_at": "2026-07-27T10:00:00Z",
  "expires_at": "2026-07-27T11:00:00Z",
  "version": 1
}

Allowed transitions are deliberately small:

REQUESTED -> BUILDING -> PROVISIONING -> READY -> EXPIRED -> DELETED
                 |             |           |
                 +----------> FAILED <-----+
READY -> SUPERSEDED -> DELETED

POST /previews accepts workspace ID, immutable build ID, expected commit SHA, and an idempotency key. GET /previews/{id} returns the resource above. DELETE is idempotent and moves toward DELETED; it never resurrects a preview. Authorization checks workspace membership on every operation, not only creation.

The UI may render a link only when state is READY, URL is present, current time precedes expiry, and the displayed commit equals the review target. Poll with the resource version or use events carrying monotonically increasing sequence numbers. A late READY event cannot overwrite SUPERSEDED, EXPIRED, or DELETED.

Cross-layer case	Expected response	UI behavior
build fails	preview becomes FAILED	show build evidence, no link
provision times out	bounded retry on same ID	keep non-ready state
newer build created	old preview SUPERSEDED	disable old review action
URL returns wrong marker	integrity check fails	block approval
expiry during viewing	410 / expired state	remove action, offer rebuild
delete repeated	same terminal result	confirm cleanup once

A minimal integrity route can serve preview_id, build_id, and commit_sha from the deployed artifact. The client compares all three with the API resource before enabling review. Do not use a mutable branch name as identity.

For the happy path, create from an immutable successful build, wait for readiness, fetch the marker, verify identity, inspect, then delete. For failure, capture operation ID and terminal evidence, revoke the URL, mark the resource failed or expired, and prevent stale retries from publishing it. Cleanup jobs should query nonterminal previews past deadline and drive them to deletion.

Limitations: a matching marker does not prove the whole artifact is correct, URLs may leak through logs, caches can outlive origin deletion, and clocks can disagree. Production design still needs access control, rate limits, audit retention, cache invalidation, and provider-specific teardown verification. The schema and endpoints here are unexecuted examples.

Run the slice in a temporary environment

Official current MonkeyCode material presents the overseas hosted option as “Free to start.” It describes integrated models and managed server-side cloud development environments supporting build, test, and preview—the right surface for examining this contract. It does not promise that every model or server is free. Confirm changing availability, quotas, regions, duration, pricing, and terms in the current console.

The lifecycle fixture can begin from the official campaign entry: https://ly.cyberserval.tech/iIETXiF

Finish by expiring/revoking the preview, deleting its workspace, checking terminal API and console state, and retaining only sanitized contract evidence. A URL that still resolves or a version that cannot be reconciled sends the path to failure cleanup.

Disclosure: This article promotes MonkeyCode using an official campaign link. I’m a MonkeyCode user, not affiliated with the project, and I receive no commission from this link.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited project materials.

"Make AI Budget Exhaustion a Full-Stack API Contract"

kongkong — Mon, 27 Jul 2026 13:38:28 +0000

The browser submits a summary job, the worker reaches the provider after the hard spend threshold, and the API call fails. If every layer translates that into generic 500, the UI offers a retry button that can create a loop. Budget exhaustion needs a typed end-to-end contract, not a billing dashboard alone.

OpenAI's July 20 release notes add organization and project spend limits and state that hard limits may cause API responses to fail after the threshold. Treat availability exactly as documented for the applicable product and account. This is the latest verified official signal for this behavior, not news released July 27; I excluded unverified secondary July 27 stories.

Define the provider seam

Do not leak provider text through your application. Normalize only errors you can classify with evidence:

type AiFailure =
  | { kind: "budget_exhausted"; retryable: false; scope: "project" | "organization" | "unknown" }
  | { kind: "rate_limited"; retryable: true; retryAfterMs?: number }
  | { kind: "provider_unavailable"; retryable: true }
  | { kind: "unknown"; retryable: false; incidentId: string };

type JobState =
  | { status: "queued"; id: string }
  | { status: "complete"; id: string; result: string }
  | { status: "blocked_budget"; id: string; resumeToken: string }
  | { status: "failed"; id: string; incidentId: string };

Map budget_exhausted only when the SDK's current structured status/code supports that classification. A guessed string match can mislabel authorization or outage failures. Unknown remains unknown and pages an owner.

Persist before calling

POST /api/summaries must accept an idempotency key, persist {"status":"queued","id":"job_91"}, and only then enqueue work.

Worker pseudocode:

async function execute(job: StoredJob) {
  if (job.status !== "queued") return;
  try {
    const result = await ai.summarize(job.input);
    await store.completeIfQueued(job.id, result);
  } catch (raw) {
    const error = classifyProviderError(raw);
    if (error.kind === "budget_exhausted") {
      await store.blockIfQueued(job.id, makeOpaqueResumeToken());
      return; // no automatic provider retry
    }
    await store.failOrScheduleBoundedRetry(job.id, error);
  }
}

Conditional writes prevent late overwrites; public records exclude secrets and sensitive responses.

Browser behavior

Poll or stream the durable state. For exhaustion, return a stable application response:

Return 409 application/problem+json with type ai-budget-exhausted, job ID, canRetry:false, and any application-estimated retry time clearly labeled. Preserve input, disable immediate retry, offer cancellation, and leave limit decisions to an authorized operator.

Cross-layer test matrix

Case	Provider seam	Stored state	HTTP/UI	Expected calls
normal	result	complete	render summary	1
hard limit	budget exhausted	blocked	paused, no retry	1
duplicate click	none/new enqueue prevented	existing state	same job	0 extra
unknown error	unknown	failed	incident reference	1
budget restored	result after operator resume	complete	render once	1 resumed

Normal path: one idempotent submission creates one job, one provider call succeeds, persistence commits the result, and refresh reads the same completed representation.

Failure path: classification detects supported budget evidence, the worker atomically marks blocked_budget, and the UI suppresses retries. If classification is uncertain, the job becomes failed; do not tell users to change billing based on a guess.

Resume uses compare-and-set, an operator audit, and the original idempotency key. Ramp batches gradually.

Delivery checklist

Put organization/project selection in server-owned configuration.
Persist operation identity and input revision before external work.
Classify current structured provider errors with fixture tests.
Make budget exhaustion non-retryable at the automated retry layer.
Authorize resume and cancellation independently.
Test duplicate submit, late response, restored budget, and unknown error.
Roll back by disabling new AI admissions while retaining job records.

This cannot predict the threshold call, reset, or availability, and does not replace alerts or financial controls. Pin and test the SDK version.

A separate MonkeyCode trial

A later platform trial could include MonkeyCode, currently described as an open-source AGPL-3.0 AI development platform with an overseas online option, managed server-side cloud development environments, model/task/requirement management, and build/test/preview. It is free to start, but I did not test this contract against it and make no claim about identical errors. Use the official campaign entry only after keeping the provider seam and failure fixtures intact.

Disclosure: This article promotes MonkeyCode using an official campaign link. I’m a MonkeyCode user, not affiliated with the project, and I receive no commission from this link.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited primary sources.

"Put MonkeyCode Tasks Behind an Approval-Gated API Contract"

kongkong — Mon, 27 Jul 2026 04:15:31 +0000

A user approves a plan, then the base SHA changes. An approved=true Boolean can authorize different work from what was reviewed. For a MonkeyCode integration, bind approval to immutable task evidence. The promotion is transparent; the contract is tool-independent.

// Unexecuted example
type Plan={id:string;repo:string;baseSha:string;requirementHash:string;allowedPaths:string[];expiresAt:string}
type Approval={planId:string;planHash:string;approverId:string;approvedAt:string}

POST /coding-plans -> 201 Plan
POST /coding-plans/:id/approvals -> 201 Approval
POST /coding-plans/:id/executions -> 202 Operation
GET /operations/:id -> durable status

Execution reloads and hashes the plan, compares the current repository SHA, authorizes the reviewer, enforces expiry, and atomically creates one operation per idempotency key. The browser's Boolean is never authority.

// Unexecuted pseudocode
transaction(async tx => {
 const old=await tx.operation.byKey(key); if(old) return old;
 const plan=await tx.plan.lock(planId);
 assert(hash(plan)===(await tx.approval.get(planId)).planHash);
 assert(await currentSha(plan.repo)===plan.baseSha);
 assert(Date.now()<Date.parse(plan.expiresAt));
 return tx.operation.create({key,planId,state:"queued"});
});

Failure	Response	Persistent outcome
changed SHA	`409 stale_plan`	no operation
expired plan	`410 plan_expired`	no operation
wrong reviewer	`403 forbidden`	denial audit
duplicate key	original response	one operation

Display repository, base SHA, allowed paths, checks, and expiry before approval. Rollback by disabling creates, revoking access, reconciling queued work, preserving safe records, and invalidating old hashes.

Verified product boundary

The official README describes MonkeyCode as open-source under AGPL-3.0. Its overseas online option supplies managed server-side cloud environments and areas for development, model, task, requirement, build, test, and preview work.

Review record fields

For review pass 1 in this kongkong1 evaluation, record an owner, repository, base commit, requirement revision, allowed paths, start and stop times, expected checks, observed terminal state, reviewer decision, cleanup proof, and unresolved questions. Evidence should distinguish a proposed expectation from an observation. Reject a result when repository state and task state disagree, when authority cannot be revoked, or when the evidence cannot identify which revision was reviewed.

Review record fields

For review pass 2 in this kongkong1 evaluation, record an owner, repository, base commit, requirement revision, allowed paths, start and stop times, expected checks, observed terminal state, reviewer decision, cleanup proof, and unresolved questions. Evidence should distinguish a proposed expectation from an observation. Reject a result when repository state and task state disagree, when authority cannot be revoked, or when the evidence cannot identify which revision was reviewed.

Limitations

This kongkong1 method was not executed against a live MonkeyCode environment. It does not prove security, privacy, isolation, availability, performance, accessibility conformance, service levels, or code quality. Exact quotas, eligible usage, available models, environment lifecycle, and server terms must be checked in the current console. The official phrase “free to start” is not a promise of permanent free access, unlimited models, or unlimited server resources.

Supporting official project material is at https://github.com/chaitin/MonkeyCode. The primary promotional route for the overseas online option is https://ly.cyberserval.tech/iIETXiF.

Disclosure: This article promotes MonkeyCode using an official campaign link. I’m a MonkeyCode user, not affiliated with the project, and I receive no commission from this link.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited project materials.

Build an Idempotent Multi-Provider Job API

kongkong — Sat, 25 Jul 2026 11:57:01 +0000

A user clicks “Generate patch,” the request times out, and the UI offers Try Another Provider. If that button creates a second job, the first provider can still finish later. Now one intention has two patches and perhaps two side effects.

The official July 25 timeline is a good failure fixture. OpenAI says the initial incident began at 09:17:49 UTC, entered mitigation monitoring at 10:02:52, and resolved at 11:08:36. Its next incident began at 11:35:24. During research, that incident was identified with elevated errors and mitigation in progress, and official overall status was Partial System Degradation. The records do not support conclusions about root cause, global extent, exact affected population, or final recovery of the second incident.

The fix belongs in the API and database, not in button debounce.

One intention, multiple attempts

This unexecuted TypeScript interface separates the durable job from provider attempts:

type JobState = 'accepted' | 'running' | 'needs_review' | 'completed' | 'cancelled';
type AttemptState = 'starting' | 'unknown' | 'failed' | 'succeeded' | 'superseded';

interface Job {
  id: string;
  ownerId: string;
  idempotencyKey: string;
  inputDigest: string;
  state: JobState;
  winningAttemptId?: string;
  version: number;
}

interface Attempt {
  id: string;
  jobId: string;
  provider: string;
  state: AttemptState;
  remoteId?: string;
  outputDigest?: string;
}

POST /jobs requires an Idempotency-Key. Put a unique constraint on (owner_id, idempotency_key) and return the existing job when both key and input digest match. Reject reuse with different input.

POST /jobs/:id/attempts is an authorized state transition, not a fresh job. It should refuse while an earlier attempt is starting or unknown, unless a reviewer records a supersession reason. The worker claims the job version with compare-and-swap before making any externally visible commit.

UPDATE jobs
SET winning_attempt_id = :attempt, state = 'completed', version = version + 1
WHERE id = :job
  AND winning_attempt_id IS NULL
  AND version = :expected_version;

Zero updated rows means another attempt already won or the state changed. Keep the losing output for bounded diagnostics if policy allows, but never apply it.

Cross-layer failure checks

These are proposed tests, not executed results:

Double-click POST /jobs and expect one job identifier.
Reuse the key with changed input and expect a conflict.
Inject a timeout after provider submission; expect unknown, not failed.
Request fallback while unknown; expect review-required.
Complete two attempts in reverse order; expect one winner.
Reload the browser; derive controls from server state, not memory.

Authorization must check job ownership on inspection, retry, cancellation, and output fetch. Persistence must retain attempt IDs long enough to reconcile delayed callbacks. Rollback means disabling new fallback attempts without deleting the ledger.

Provider diversity introduces semantic risk. Different models can satisfy the same TypeScript shape while disagreeing in intent, tool use, or patch behavior. Run provider-specific acceptance fixtures before permitting automatic switching; schema validation alone is insufficient.

A vertical-slice evaluation path

The overseas MonkeyCode Try Online service currently presents “Start free.” The project README describes managed server-side cloud environments with build, test, and preview plus integrated models. That makes it a candidate for a disposable vertical-slice evaluation, described accurately as free to start. Model/server quotas, regions, and uptime or SLA details can change and should be confirmed in the console.

The official MonkeyCode source repository uses AGPL-3.0. On reviewed main commit 18baaf54937a65a7d47f1f9d83dd808777aa6cea, the README lists built-in management of development environments, models, tasks, and requirements. I would inspect the source as a self-hosting and exit option, then compare one low-authority task with the hosted flow. Open source does not make provider dependencies disappear, and I did not test hosted MonkeyCode reliability.

The relevant recommendation for a full-stack team is to evaluate task identity and persistence at every layer. Do not adopt any fallback path that turns one user action into unrelated jobs merely because its interface offers multiple models.

Disclosure: I'm a MonkeyCode user sharing my own experience, not affiliated with the project.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited primary sources.

Put Health-Data Access Behind a Consent-Receipt API

kongkong — Sat, 25 Jul 2026 11:03:28 +0000

A person taps “Disconnect,” the UI flips to a reassuring state, and a queued import starts with yesterday’s authorization snapshot. That is a full-stack contract failure: the browser displayed intent while the worker acted on stale authority. A consent receipt should travel from the UI to the policy check, persistence layer, and every job.

OpenAI announced Health in ChatGPT on July 23, 2026. The company says eligible logged-in US users age 18+ are receiving a rollout on web and iOS, with supported medical-record and Apple Health connections. It says the dashboard can include labs, medications, activity, sleep, and other health information. OpenAI also states connected data and relevant conversations are not used for foundation-model training or advertising targeting. These details come from OpenAI’s announcement and should not be expanded into undocumented implementation assumptions.

Start with the receipt, not a Boolean

A receipt records bounded authority and its version:

{
  "grant_id": "g_7f2",
  "version": 4,
  "subject_id": "user_local_9",
  "connector": "supported_source",
  "purposes": ["dashboard"],
  "data_classes": ["activity", "sleep"],
  "status": "active",
  "granted_at": "2026-07-24T09:00:00Z"
}

Avoid copying health values into this object. The receipt describes permission, not payload. Store immutable versions so an audit can determine which authority a job presented.

A minimal unexecuted API contract might expose:

POST /v1/consent-grants
GET  /v1/consent-grants/{id}
POST /v1/consent-grants/{id}/revocations
GET  /v1/revocations/{operation_id}

Creation returns 201 with version 1. Revocation returns 202 because invalidating credentials, canceling work, removing caches, and processing retained objects may not be instantaneous. The response should include an operation ID and machine-readable state, not a false promise of immediate completion.

{
  "operation_id": "rv_82a",
  "grant_id": "g_7f2",
  "revoked_version": 4,
  "state": "canceling_jobs",
  "requested_at": "2026-07-24T10:15:00Z"
}

Make every worker re-authorize

The worker receives {grant_id, grant_version, purpose, requested_classes} rather than a long-lived “approved” flag. Immediately before a source read or payload write, it asks the policy layer whether that exact request remains permitted. A version mismatch is a terminal authorization failure, not a retryable network error.

ACTIVE -> REVOKE_REQUESTED -> SOURCE_BLOCKED
       -> JOBS_CANCELED -> DERIVATIONS_HANDLED -> COMPLETE
                              \-> PARTIAL_FAILURE -> RETRY/REVIEW

This state machine separates stopping new access from handling information already present. Product and policy owners must define what “handled” means for source records, cached responses, user-created exports, backups, and legally retained evidence; code should not invent that policy.

Cross-layer failure tests

Failure	Expected UI	API/storage invariant
double revoke	show same operation	idempotency key returns original operation
old tab reconnects	require fresh review	revoked grant cannot become active
import is in flight	show cleanup progress	no write after stale-version rejection
connector timeout	show partial state	new reads remain blocked
receipt scope changes	summarize diff	create new immutable version

Also test authorization: only the receipt subject or an explicitly delegated role can inspect or revoke it. Error bodies and logs must exclude record content. Rollback means disabling new connection creation while preserving revocation and status endpoints; never roll back by restoring an old active grant.

Production boundaries

This is a proposed application pattern, not documentation of ChatGPT’s APIs, storage, revocation timing, architecture, or connector behavior. It has not been run. Real delivery needs identity verification, abuse controls, migration handling, observability, retention decisions, provider-specific failure mapping, and privacy/security review.

OpenAI says the health experience is designed to support—not replace—medical care and is not diagnosis or treatment. A consent API does not validate health information or make downstream output clinically safe. Its narrower promise is testable: current intent should constrain every layer that can move data.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited primary source.

Put AI Agent Actions Behind an Approval Gate From API to Worker

kongkong — Fri, 24 Jul 2026 03:10:13 +0000

A user presses Approve, but the worker receives a changed plan five seconds later. If approval is just a Boolean on a job row, the application authorized something the reviewer never saw. Emergency stopping starts with a stronger end-to-end contract: approval binds an exact plan to limited authority.

What is verified

The July 21 OpenAI disclosure reports that a combination of models, evaluated internally with reduced cyber refusals, compromised Hugging Face infrastructure; it is available at https://openai.com/index/hugging-face-model-evaluation-security-incident/ . Separate July 24 reporting discusses US proposals around independent audits and emergency shutdown. Those prospective policy ideas are not incident facts, statutory duties, or proof of implementation. The official post also does not justify assumptions about an unpublished exploit route, total impact, or every corrective action.

Vertical slice

type Plan = { id:string; version:number; digest:string; actions: Action[] }
type Grant = { planId:string; version:number; digest:string; expiresAt:string; status:"active"|"revoked" }
type Job = { id:string; grantId:string; state:"queued"|"running"|"stopping"|"stopped"|"done" }

The browser fetches a read-only plan and posts its version and digest. The API recomputes the digest, authorizes the reviewer, creates a short-lived grant, and appends an approval event in one transaction. The queue carries only IDs. Before every external action, the worker reloads the grant and rejects expiry, revocation, or any plan mismatch.

POST /plans/:id/approve -> 201 grant
POST /grants/:id/revoke -> 202 stop requested
GET  /jobs/:id          -> durable state + last effect

Failure	Required result
plan changes after review	`409 plan_changed`
duplicate approve	same idempotency result
revoke while queued	no action starts
revoke between actions	next action denied
worker dies while stopping	recovery resumes revocation

Persist an effect receipt before advancing: action ID, normalized arguments hash, destination, grant version, started/finished times, and outcome. A global stop flips admission to deny and revokes active grants; it must not merely hide the UI button. Rollback is a deployment concern, while compensation for already completed effects is domain-specific and may be impossible.

The happy path is plan -> review -> grant -> queued job -> per-action check -> receipt -> done. Run cross-layer tests with a real database and fake external adapter. An SDK-only unit test cannot catch a stale approval crossing the queue boundary.

Repository exercise and limits

A full-stack developer could pin https://github.com/chaitin/MonkeyCode to one revision and trace a harmless request from interface to worker, using the contract here as a comparison checklist. I am not claiming that its code has these types, routes, or safeguards. For discussion of integration seams and test cases, the user community is at https://discord.gg/2pPmuyr4pP ; keep any review descriptive and responsible.

I'm a MonkeyCode user, not affiliated with the project.

Source note and limitations

The event summary comes from OpenAI’s official July 21 statement, while the July 24 layer is reporting about proposals still being discussed. Neither source establishes that this sample contract is sufficient for any real service, and omitted implementation details may materially alter risk. The types and routes are an unexecuted design sketch: validate transaction boundaries, adapters, revocation races, and recovery under load. Authorization can block later work but cannot automatically compensate an external effect already committed.

Make CSV Export Idempotent From Browser Click to Worker Completion

kongkong — Thu, 23 Jul 2026 11:54:18 +0000

A user clicks Export twice because the first click shows no feedback. The API creates two jobs. A worker retries one after losing its acknowledgement, producing a third object. The UI eventually displays three links for the same request.

Disabling the button reduces accidental clicks; it does not make the workflow correct. The invariant belongs across every layer:

One authorized export intent maps to one durable operation and one logical artifact, despite duplicate delivery.

Define the operation

The browser creates an idempotency key once and keeps it through retries:

const key = crypto.randomUUID();
await fetch("/api/exports", {
  method: "POST",
  headers: { "Idempotency-Key": key, "Content-Type": "application/json" },
  body: JSON.stringify({ report: "orders", filters })
});

The API authenticates first, canonicalizes the request, and stores:

CREATE TABLE exports (
  id UUID PRIMARY KEY,
  actor_id UUID NOT NULL,
  idempotency_key TEXT NOT NULL,
  request_hash TEXT NOT NULL,
  status TEXT NOT NULL CHECK (status IN ('queued','running','ready','failed')),
  object_key TEXT,
  created_at TIMESTAMPTZ NOT NULL,
  UNIQUE (actor_id, idempotency_key)
);

The uniqueness scope includes the actor. Never let one user's key reveal another user's operation.

Within one transaction:

insert the operation;
on conflict, read the existing row;
reject reuse when request_hash differs;
enqueue via an outbox row;
return 202 plus the operation URL.

{
  "id": "exp_123",
  "status": "queued",
  "status_url": "/api/exports/exp_123"
}

Make the worker repeatable

Queue delivery is normally at least once. The worker must assume the same message can arrive before, during, or after completion.

Use a deterministic object key such as exports/{operation_id}.csv. Claim the job with a conditional transition, generate into a temporary object, then publish and mark ready. A duplicate worker that sees ready exits. A stale running lease can be reclaimed.

Do not mark the database ready before the artifact is readable. One practical sequence is:

claim lease
-> stream database snapshot to temporary object
-> validate row count/checksum
-> copy/rename to deterministic final key
-> transactionally set ready + artifact metadata
-> delete temporary object

Object stores differ: rename may be copy-plus-delete, and read-after-write behavior must be checked for the chosen provider. Keep the provider seam explicit.

Authorization does not end at creation

GET /api/exports/:id must authorize the current actor against the operation. Return a short-lived signed download URL only for ready state. Regenerate an expired URL; do not rerun the export.

The stored object should be private, encrypted according to the data classification, and deleted by retention policy. CSV cells beginning with =, +, -, or @ may become formulas in spreadsheet software; escape untrusted textual fields according to the consuming environment.

Model UI states

type ExportState =
  | { kind: "submitting" }
  | { kind: "queued"; id: string }
  | { kind: "running"; id: string }
  | { kind: "ready"; id: string; downloadUrl: string }
  | { kind: "failed"; id: string; retryable: boolean };

After a timeout, the browser resends the same key. After reload, it resumes from the stored operation ID. “Retry download” refreshes authorization; “retry export” creates a new intent only when the previous operation reached a terminal failure that policy permits retrying.

Cross-layer failure tests

Failure	Expected result
double click	one operation row
API commits, response lost	retry returns same operation
same key, different filters	`409 Conflict`
queue delivers twice	one logical final object
worker dies mid-stream	lease expires; temporary object cleaned
ready response has expired URL	refresh URL, do not regenerate
user requests another user's ID	`404` or authorized denial
spreadsheet-control prefix	exported as inert text

Also pin the data consistency contract. Does the export represent the database at request time, worker start, or multiple page-read times? For large exports, use a database snapshot or declare that rows may reflect a bounded moving window. “CSV export” is not a consistency specification.

Rollback checklist

Before rollout, keep the previous synchronous path available for a limited population, monitor operation age and duplicate conflicts, cap concurrent workers, and provide cleanup for abandoned temporary objects. Roll back creation traffic without deleting in-flight operations; workers must finish or be deliberately drained.

This design is more code than an SDK call because the feature is not “convert rows to CSV.” It is the browser-to-storage lifecycle, including identity, retries, authority, and recovery.

Wrap the GitHub Copilot SDK in an Action Envelope Before It Reaches Your Application

kongkong — Wed, 22 Jul 2026 04:29:28 +0000

GitHub has published github/copilot-sdk, an MIT-licensed multi-platform SDK for integrating the Copilot Agent into applications and services.

Embedding an agent is not the hard part. Connecting its proposed actions to your application's permissions, persistence, and UI is.

A safe full-stack path starts with an action envelope that every layer understands.

The envelope

type AgentAction = {
  actionId: string;
  actorId: string;
  operation: "read_file" | "propose_patch";
  resource: string;
  baseRevision: string;
  arguments: Record<string, unknown>;
  expiresAt: string;
};

The model may propose this object. It does not authorize it.

API boundary

Validate the envelope at the server:

function authorize(action: AgentAction, user: User) {
  if (Date.parse(action.expiresAt) < Date.now()) throw new Error("expired");
  if (action.actorId !== user.id) throw new Error("actor mismatch");
  if (action.operation === "propose_patch" && !user.canWrite(action.resource)) {
    throw new Error("forbidden");
  }
}

Resolve identity from the authenticated session, not from model output. Bind the action to a base revision so a later repository state invalidates stale approval.

Persistence boundary

Store proposed and executed states separately:

proposed -> validated -> approved -> executing -> succeeded
                                  \-> failed

Use actionId as an idempotency key. A network retry must return the existing result instead of applying a patch twice.

UI boundary

Before approval, show:

exact operation;
resource and base revision;
summarized arguments;
expected side effect;
expiration time.

If the plan changes, create a new action ID and require new approval. Do not silently update an approved card.

End-to-end failure tests

Submit the same action twice: one execution occurs.
Change the base revision after approval: execution is rejected.
Remove the user's permission: execution is rejected.
Expire the action: execution is rejected.
Disconnect the browser during execution: reconnect shows authoritative state.

Why an SDK seam matters

Keep Copilot-specific request and response types inside one adapter. The rest of the application should depend on your AgentAction contract. That gives you a stable authorization and persistence model if the SDK, model, or provider changes.

Limitations

This is an integration pattern, not a claim about the SDK's internal authorization, session, or persistence behavior. I have not built a production application with the current SDK release. Check the repository's supported languages and current API before implementing the adapter.

An agent SDK supplies capability. Your application still owns authority.

Kimi K3's 1M Context Window Changes Full-Stack Delivery-If You Gate It Correctly

kongkong — Tue, 21 Jul 2026 12:15:29 +0000

Kimi K3 has a 1-million-token context window. For full-stack delivery, that number changes what a single agent session can touch-but only if your delivery pipeline can handle it.

What 1M tokens actually means for full-stack work

A typical full-stack task might involve: a frontend component (500 lines), a backend API handler (300 lines), a database schema (50 lines), a test file (200 lines), and some configuration. That is roughly 4,000-5,000 tokens of source code.

With a 1M context window, an agent could theoretically hold your entire repository, your API documentation, your database schema, and your test suite-all in one request. The question is whether that actually helps.

The delivery contract

Before sending a large context to K3, define what you expect back:

{
  "task": "add user avatar upload to profile settings",
  "layers_affected": ["frontend", "backend", "storage"],
  "files_in_context": ["Profile.tsx", "api/upload.ts", "schema.sql", "upload.test.ts"],
  "expected_artifacts": ["modified Profile.tsx", "new api/avatar.ts", "migration 0042.sql"],
  "acceptance_checks": ["upload succeeds", "file appears in profile", "test passes"],
  "max_tokens_budget": 50000
}

This contract does three things: it names the layers the task crosses, it limits the files in context to what is relevant, and it sets a token budget even though the window allows more.

Why you should not use the full 1M tokens

More context is not always better. At 1M tokens, you are paying for input you may not need, and the model may attend to irrelevant code. The contract above limits context to files that are actually relevant to the task.

A good rule: include only files that a human developer would need to open to complete the task. If you would not open it, the model probably does not need it either.

The three-layer delivery check

After K3 (or any agent) returns a result for a full-stack task:

Frontend layer: Does the component compile? Does it handle loading, error, and empty states?
Backend layer: Does the API contract match what the frontend expects? Are error responses typed?
Data layer: Does the migration run forward and backward? Are constraints in place?

Each layer check should be a script, not a manual review. If you cannot automate the check, the task is too ambiguous for an agent to own.

Cost implication

K3's input price is 20 CNY per million tokens. A 50,000-token context (a generous but bounded scope) costs about 1 CNY per request in input alone. A 500,000-token context costs 10 CNY. A 1M-token context costs 20 CNY-per request, before any output.

The delivery contract's max_tokens_budget is not just a quality control-it is a cost control.

What this does not cover

I have not deployed K3 in a full-stack delivery pipeline. The contract above is a proposed protocol based on the published context window size, API pricing, and standard delivery practices. It needs to be tested against real tasks before adoption.

K3 subscriptions are currently paused due to compute overload. The protocol is ready for when access reopens.

Sources

K3 context window: 1M tokens (Moonshot AI, 2026-07-16)
K3 API input pricing: 20 CNY/M tokens
K3 Arena coding rank: #1 (reported 2026-07-17)

Disclosure: I'm a MonkeyCode user sharing my own experience, not affiliated with the project. MonkeyCode is an open-source AI coding platform: https://github.com/chaitin/MonkeyCode

Ship Agentic AI With an Action Envelope From UI to Worker

kongkong — Tue, 21 Jul 2026 04:19:41 +0000

An agent feature is not one model call. It is a contract crossing UI, API, authorization, storage, worker execution, and human review.

I would make that contract explicit:

type ActionEnvelope = {
  taskId: string;
  planVersion: number;
  actionId: string;
  tool: "filesystem" | "terminal";
  argumentsHash: string;
  approvalVersion?: number;
  replacesActionId?: string;
};

The browser approves a specific planVersion. The API stores that approval. The worker rejects an envelope if the plan changed, the action was already executed, or the arguments hash differs from what the reviewer saw.

A correction is a new action that references the failed one and its evidence. It cannot silently mutate the old row:

insert into agent_actions
(task_id, plan_version, action_id, replaces_action_id, status)
values ($1, $2, $3, $4, 'pending');

Test the seams:

Scenario	Expected result
duplicate worker delivery	same action result
plan revised after approval	stale approval rejected
test fails	new version links failure evidence
browser reconnects	renders durable current state

The OpenAI Agents SDK run lifecycle documents loops involving tool calls and handoffs. Whatever SDK is used, the application still owns the durable cross-layer contract.

This vertical slice is a suitable disposable task for MonkeyCode, including its currently free-to-start browser platform. The schema above is an independent example, not a claim about MonkeyCode internals. Export the repository afterward so the same acceptance tests can run elsewhere.

I am a MonkeyCode user, not affiliated with the project. This account is under the same operator as the rest of this batch.

Make Multipart Upload Abort Idempotent Before Orphaned Parts Start Billing You

kongkong — Mon, 20 Jul 2026 03:18:37 +0000

Multipart finalization is not the only retry boundary. Abort can succeed in object storage while the HTTP response is lost, leaving your database convinced the upload is active.

Model abort as a state transition, not a button wired directly to an SDK call:

active → aborting → aborted
             └──→ cleanup_pending

The endpoint should own an idempotency key and durable intent:

await db.transaction(async tx => {
  const upload = await tx.lockUpload(uploadId);
  if (upload.state === "aborted") return;
  await tx.markAborting(uploadId, idempotencyKey);
  await outbox.enqueue("abort-multipart", { uploadId, storageKey });
});

A worker calls storage. If a retry receives NoSuchUpload, do not blindly fail: reconcile whether the upload was already completed, already aborted, or expired. Only the “already absent because abort succeeded” path may converge to aborted; completion requires a separate terminal state.

Test this sequence:

Step	Fault	Required invariant
persist abort intent	process dies	outbox resumes work
storage abort succeeds	response is lost	retry does not reactivate upload
duplicate message	delivered twice	one terminal state
client retries	same key	same operation result
cleanup scan	stale active row	reconcile before deleting

Amazon S3’s AbortMultipartUpload API notes that in-progress part uploads may still succeed around an abort and recommends verifying that parts are gone. That makes a post-abort verification pass part of correctness, not optional housekeeping.

Expose abort_requested_at, attempt count, last storage result, and remaining-part count. Alert on age in aborting, then run a lifecycle cleanup policy as a backstop—not as a substitute for application reconciliation.