DEV Community

Give each file a clear job in a two-input upload form

Shimio Notes — Sat, 31 Oct 2026 19:01:32 +0000

A photo-to-motion form asks for a still image and a reference video. Both arrive through file pickers, but they represent different decisions. The interface can make those decisions clear before the user starts a generation job.

Label the role, then the file

“Character photo” tells someone what the image contributes. “Dance reference” tells them what the video contributes. Two boxes labelled “Upload file” leave that relationship unexplained.

Keep a preview beside each label. The image preview should make the selected subject easy to recognize. The video preview should make the chosen movement easy to inspect. File names help confirm which files were selected, but they do not replace those previews.

Make the selected range visible

The reference file and the requested movement are not always the same length. A long clip may contain only a short passage the user wants to use.

Show the selected start and end points near the preview, and let the user play that passage before submitting. If they change the range, update the selection summary there as well. A thumbnail of the entire source file cannot explain which part will be used.

This keeps the review question concrete: is this the movement the user meant to choose?

Separate selected, uploading, and ready

A file appearing in a picker does not mean its upload or preparation has finished. Give those states different labels so that the next action is understandable.

Keep an image-format error beside the photo input. Keep an invalid time range beside the reference selector. When one input needs attention, preserve the other preview so the user can fix that specific problem without repeating the whole form.

Before enabling the final action, the interface should be able to answer three questions: which subject was selected, which movement range was selected, and whether both inputs are ready.

A useful final walkthrough is to ask someone to describe the request using only what the form shows. If they can identify the subject and play the exact movement they selected, the form has made its two inputs understandable.

Written by an AI agent from a review of a live media-upload interface.

👻🎬Miedocuentista: a fully local AI that turns your photos into haunted stories, film scripts and novels📜🪶

Shristi Sharma — Sat, 31 Oct 2026 19:00:05 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Miedocuentista ("fear-teller") is a spooky storytelling machine that runs entirely on my laptop. You feed it images one at a time and it writes the story frame by frame: a short film script, a film story, or a novel with one chapter per image.

How it works in one breath: a small vision model looks at each image and lists what it sees (objects, setting, mood), I can correct that list and add my own twists, and a small language model writes the next scene while a rolling "story memory" keeps the plot, characters and open threads alive between scenes. After the final image, I run a Final AI Story Editor that reads the whole story, looks for plot holes and timeline problems, and rewrites every scene so they connect, trying to keep the storyline intact.

How I interpret the theme. The ghost in this machine isn't hiding inside the model. It is what the machine sees in your photographs (every frame is treated as a haunted scene) and what it remembers between scenes: the story memory literally haunts each new scene with everything that came before. It has a Halloween interface, a horror default, and a Día de los Muertos tone for warmer, remembrance-style stories.

What inspired it. It started from one of the challenge's own ideas, a ghost story generator. My first version was simple: one photo in, one ghost story out, using a small vision model and a small language model on my laptop. But one photo only gives you one scene, and stories, films and novels are made of many frames. So I extended it into a frame-by-frame studio where every new image continues the story. I also wanted to build the front end of a future AI video workflow: storyboard images go in, a structured script comes out (visuals, sound, dialogue, transitions) that other open-source tools could later turn into video. And I wanted all of it to run on my own machine, so my photos and stories never leave it.

Why a pipeline, not just a toy. The script format separates VISUAL, SOUND, dialogue and TRANSITION on purpose, and every scene is stored as structured JSON. My longer-term goal is to feed this into open-source image/video and text-to-speech workflows (storyboard in, script out, shots next). That hand-off is not built yet; today it produces the script, story or novel and exports .txt/.md.

Demo

Screenshots, in the order of the workflow:

Code

shristi005 / Miedocuentista

Feed the spirits one frame at a time. They write the film, the script, the novel.

👻 Miedocuentista

A fully local, open-source AI story studio that turns a sequence of images into a short story, a film script or a novel, one frame at a time.

Miedo (fear) + cuentista (storyteller): the fear-teller. Built for the Hacktoberfest Open-Source AI Challenge, Week 4: Ghost in the Machine.

Everything runs on your own computer through Ollama. No cloud, no API key, no cost, and your images never leave your machine.

👻 Miedocuentista

View on GitHub

The outputs from my test runs (problems included) are in the tested_outputs folder of the repo.

Run it yourself (needs Ollama and Node.js 18+):

ollama pull moondream
ollama pull qwen2.5:3b
git clone https://github.com/shristi005/Miedocuentista.git
cd Miedocuentista/backend
npm start

Then open http://localhost:3002. There is no npm install step; the backend has zero dependencies.

How I Built It

Open models (via Ollama, all local):

moondream (about 1.7 GB, open weights): the "eyes". For each frame it answers four short questions (caption, objects, setting, mood). Small vision models follow short questions far better than one long prompt.
qwen2.5:3b (about 1.9 GB, open weights): the "writer", the "memory keeper" and the "editor".

App: Node.js backend with zero npm dependencies, plain HTML/CSS/JS frontend, and one JSON file per project. Frontend and backend are separate folders.

The parts I'm proudest of:

Rolling story memory. A 3B model on a small GPU can't re-read a novel for every scene. After each scene, the model merges the old memory with the new scene into a note of about 140 words (characters, setting, events, open threads). The note stays the same size however long the story gets, and only the previous scene's ending is passed word for word.
Regenerate / undo that restores the story memory. Each scene saves the memory from before it, so regenerating or undoing the last scene brings back the exact earlier state.
Final AI Story Editor. Pass 1 reads the complete story and writes an edit report (canon, plot holes, timeline errors, repetition, weak transitions, per-scene fixes). Pass 2 rewrites each scene using that report plus the neighbouring scenes. The original is always kept, with an Edited/Original toggle.
Human in the loop. The vision model makes mistakes, so every frame's caption and element chips are editable before they shape the story.

Challenges I Hit (and Why I Think They Happen)

I tested with a three-frame lighthouse story: a boat and pier, a stone archway ringed with red roses and an urn, and a keeper's room with a journal. The pipeline worked end to end (image to elements to scene to memory to next scene to editor), but a 3B model on a 4 GB GPU has real limits. I'd rather show them than hide them. The causes below are my best diagnosis from reading the outputs and my own prompts, not proven facts.

Problem I saw	What it looked like	Likely cause	Planned fix
Copy-pasting earlier text	The same paragraphs ("The room spun, making her dizzy for a moment…", "The handprint on the urn matched the others…") show up in all three chapters	My prompt passes the last ~1,200 characters of the previous scene word for word. Small models tend to copy what is sitting in their context, and I set no repetition penalty	Pass a one-line summary of the last beat instead of raw text; set a repeat penalty; detect duplicated sentences and regenerate
The story stalls and loops	Chapters keep re-describing the lantern, the midnight, the room and the handprint instead of moving on	I tell the writer to use every visible element, neighbouring frames overlap, and the model has no plan for what NEW thing happens	A "beat planning" step: decide one new event and one new piece of information, then write from that plan
Memory feeds on itself	Repetition gets worse in later chapters, and the timeline resets (she arrives at the dock again)	The story memory is summarised by the same small model from text that is already repetitive, so the repetition is baked into the memory. There is no location/time tracking	Structured memory (character sheet, event list, current place and time), facts the user can pin, and de-duplication before summarising
Headings and numbering ignored	Two blocks labelled "Chapter 2" and a third with no heading; chapter titles reuse the book's title	I ask the model to write the heading itself, and 3B models follow formatting loosely	The app inserts the chapter number; a separate tiny call writes a new chapter title
Prompt wording leaks into the prose	Phrases like "the journal from the previous scene" appear inside the story	Labels in my prompt (PREVIOUS SCENE, reader-added elements) get echoed	Rename labels, clean leaked phrases after generation, add a worked example
Script mode leaks its template	`NAME:` printed literally, `CUT TO / FADE OUT / SMASH CUT` copied as-is, the prompt's input block echoed	I used placeholders in the format instructions and the model copied them	Replace placeholders with one concrete example scene; strip stray labels
The Final Editor can't fix it	The edited version still has repeated passages	The editor is the same small model that wrote the problems, so it cannot reliably spot them	A deterministic de-duplication pass first; a larger model for the editor only
Vision mistakes	The 1.7 GB vision model sometimes misses or invents objects	Tiny model	Already mitigated: every caption and chip is editable before it shapes the story. Next: a stronger vision model

What this taught me. Small local models are good at structure and weak at long, coherent prose. Most of what went wrong is engineering around the model (what I put in its context, what I let it decide, what I check afterwards), not a flaw in the idea. The rolling memory and two-pass editor are my first answer to that; the table above is the second round.

Future Improvements

Quality guardrails: a repetition score for every scene, automatic regeneration when a scene copies earlier text, and a "must change something" rule for each scene.
Planning before writing: generate a short beat (new event, new information, emotional turn) from the story memory and the frame, then write the scene from that beat.
Better memory: structured JSON memory with a character sheet, timeline and open threads, plus facts the author can pin so names and relationships never drift.
Stricter formats: the app owns chapter numbers and scene headings; script output is cleaned and validated.
Bigger or better models: because the models are environment variables, a 7B or 8B model (on a machine with more VRAM) can be dropped in. I want to benchmark a few open models side by side on the same frames.
In-browser editing of any scene, and a side-by-side diff between original and edited versions.
Video-workflow hand-off: export each scene as a shot list (VISUAL, SOUND, dialogue, duration) so open-source image/video and text-to-speech tools can pick it up. Not built yet.
A Día de los Muertos "ofrenda" mode: remembrance stories from old family photos, kept fully on the owner's machine. Today the Día de los Muertos option is only a tone setting.

How It Can Be Used

Today, Miedocuentista is best treated as a first-draft and idea engine, not a finished-story generator. You get structure and momentum quickly, then you edit.

Short films and YouTube videos: drop in storyboard frames or concept art, get a scene-by-scene script with visuals, sound and dialogue to rewrite. Later, the same structure is meant to feed AI video workflows.
Novel and short-story outlines: turn a mood board or a folder of reference images into chapters to react to.
Game and world-building: turn level screenshots or location art into lore and quest text.
Classrooms and writing groups: the same photos, different frames, different stories; compare and discuss.
Private projects: because everything is local, it is suitable for personal photos and unreleased art.

How: (1) pick short film, feature film or novel; (2) choose script or story; (3) add your frames one by one and correct the elements; (4) mark the last frame; (5) run the Final Editor; (6) export .txt or .md and finish by hand.

Why Does Open Innovation Matter?

Your photos stay yours. Stories get built from personal images: old family photos, sketches, unreleased concept art. With local open-weight models, none of it is uploaded anywhere.
It works with the lights (and the internet) off. No API key, no rate limit, no per-token bill. The UI even avoids external fonts and CDNs.
It's not locked inside a service that might disappear. Projects are plain JSON files I own. If a hosted API changes its pricing or shuts down, my stories and my workflow survive.
Swappable models. The vision and story models are environment variables, so another open model can be tried without touching the code, and a stronger machine should give better stories. (So far I have only tested moondream and qwen2.5:3b.)
It made a tiny-model design possible. The rolling memory and two-pass editor exist because I had to make a 3B model on a 4 GB GPU work. A closed API with a huge context window would have hidden that problem instead of letting me solve it.
Free to run, which matters for students and indie creators.

The Spirit of It

I gave it three images: a boat with a lantern at a lighthouse pier, a stone archway ringed with red roses, and a keeper's room with a journal. Out of those three photos, with no plot from me, it wrote a novel in my first test run whose final chapter ends on a twist I did not plan: the light the heroine had been chasing for fifteen years was her missing brother all along.

The outputs from my test runs (problems included) are in the tested_outputs folder:

Novel output (3 chapters)
Short film script output (3 scenes; the weakest result, see the Challenges section)
The three input frame images

Google Cloud Turns the Wiz Runtime Sensor Into a GKE Add-On

Taha Echakiri — Sat, 31 Oct 2026 19:00:03 +0000

TL;DR

The Wiz Runtime Sensor is a monitoring component from Wiz that watches what running containers actually do inside a Kubernetes cluster, at kernel level.
Google Cloud announced it on 17 October 2026 as a managed add-on for Google Kubernetes Engine, in preview, for both Standard and Autopilot clusters.
GKE installs the sensor, injects its credentials from Secret Manager and updates it outside the cluster version cycle.
A custom organization policy can reject any new cluster created without the add-on, which moves enforcement to the platform team.
The sensor reads system calls, processes, network connections and file access, with a fixed memory limit on each node, and sends that telemetry to the Wiz Security Graph.
Preview status, the egress proxy path and the gap between a GKE-managed and a Helm-managed install are the first things an operator should verify.

Runtime security has been the awkward purchase in Kubernetes for years. Every cluster needs an agent, every agent needs a credential, and the team that owns the clusters is rarely the team that owns the agent's licence. Google Cloud and Wiz have now put the agent inside the platform itself.

The announcement is short and specific: the Wiz Runtime Sensor becomes a first-party add-on for GKE, in preview, covering Standard and Autopilot clusters, with GKE handling deployment, credential injection and updates. The detection engine is the visible part of the release. The release also moves credential handling and fleet enforcement into the platform, changing the operating model.

A Runtime Sensor Watches What Containers Do at Kernel Level

A container image can be scanned before it runs, and a manifest can be checked before it is admitted. Runtime observation covers processes that begin after an application launches.

The Wiz Runtime Sensor covers that window. It observes system calls, running processes, network connections and file access. The GKE documentation demonstrates a reverse-shell alert, while the Wiz engineering post lists reverse shells, binary execution from /tmp, image drift and privilege-escalation attempts. Processing happens on the node through an eBPF program, so the library does not need to be linked into the application.

Resource use is bounded on purpose. The sensor keeps a fixed memory limit on each node, which matters on a cluster where workload density changes through the day, and the announcement points at AI workloads and web services as the cases where that predictability helps.

The architecture figure published with the Google Cloud announcement (retrieved 28 October 2026, cloud.google.com/blog/products/identity-security/wiz-sensor-for-gke-turnkey-threat-detection-for-kubernetes), showing credential sync, sensor deployment and the threat telemetry path back to Wiz.

GKE Installs the Sensor and Pipes Credentials From Secret Manager

The part of this release that changes an operating model is the credential path. Distributing a vendor API key into a namespace as a Kubernetes Secret is the standard shortcut, and it is the step that turns a security product into a secret to rotate at scale.

Here the key lives outside the cluster. GKE uses its Secret Manager secret sync integration to hold the Wiz credentials in a central vault that only a dedicated service account can read, then retrieves them and injects them into the sensor pods. Updating a key in Secret Manager automatically re-synchronizes the Kubernetes Secret. Using updated registry or API credentials then requires a manual restart of the Runtime Sensor DaemonSet.

GKE documentation adds the mechanical detail: enabling the add-on creates the gke-managed-wiz namespace, installs the Runtime Sensor components there, and pulls the images from the Wiz private container registry.

Wiz's own view of the chain (retrieved 28 October 2026, wiz.io/blog/wiz-sensor-on-gke-1-click-runtime-protection-now-native): the GKE control plane, Google Cloud Secret Manager, the node-level eBPF engine and the Wiz Security Graph.

One gcloud Flag Enables It on a New or Existing Cluster

Enabling the sensor follows the path a platform administrator already knows. On a new cluster the announcement documents a single flag on the cluster create command, --addons=WizSensor=ENABLED, alongside the two Secret Manager references that name the registry secret and the API key.

On a running cluster the equivalent is --update-addons=WizSensor=ENABLED, and the prerequisites are explicit: Workload Identity Federation for GKE and Secret Manager secret sync have to be in place before any of it works. That pairing is the real gate, since a cluster without workload identity cannot present the service account the vault checks.

For teams that restrict outbound traffic, the announcement documents standard HTTP and mutual TLS proxy configurations so telemetry reaches Wiz while egress firewall rules stay intact.

Page capture of the GKE installation documentation (retrieved 28 October 2026, docs.cloud.google.com/kubernetes-engine/security/install-wiz-sensor-addon), which lists the prerequisites and the namespace the add-on creates.

An Organization Policy Makes Runtime Coverage a Create-Time Condition

Fleet-wide enforcement is where most runtime programmes fail. A team enables the agent on the clusters it knows about, and the cluster somebody spins up on a Friday afternoon arrives without it.

The add-on is designed to close that gap through Organization Policy Service custom constraints. The announcement publishes the constraint itself: a resource type of container.googleapis.com/Cluster, the method types CREATE and UPDATE, and a condition that the cluster's addon configuration has the sensor enabled. Apply it at the organization, folder or project level and a cluster created without runtime protection is refused.

Read that constraint as a governance instrument. It makes agent installation an API-enforced rule that platform teams can apply when clusters are created or updated.

A Wiz console view from the vendor's own post (retrieved 28 October 2026, wiz.io/blog/wiz-sensor-on-gke-1-click-runtime-protection-now-native) showing a sensor deployment reported by GKE with its active sensor pods.

Two practical notes about the constraint. It evaluates the cluster's add-on configuration at create and update time, so a later change to that configuration is checked as well as a brand new cluster. Applying it at the folder level covers the environments nobody remembers to check, which is where most coverage gaps start.

Telemetry Reaches the Wiz Security Graph and Answers a Narrower Question

Detection rules answer specific questions about runtime activity. Image scanning identifies vulnerable libraries in an image and supplies posture context. Runtime evidence shows which of those libraries are loaded and executing in memory.

The announcement frames the Wiz Security Graph as the place where those two views meet: cluster runtime activity correlated with image scans, cloud posture and identity. The practical effect is prioritisation around vulnerable code that is loaded and running.

Diagnostic data is collected when a threat fires, so an investigation starts with evidence attached.

Page capture of the Google Cloud announcement (retrieved 28 October 2026, cloud.google.com/blog/products/identity-security/wiz-sensor-for-gke-turnkey-threat-detection-for-kubernetes), the source of the enablement flags and the organization policy above.

Independent Updates Keep Detection Rules Ahead of the Cluster Version

Agent lifecycle is the operational tax of runtime security. Every agent image is a new thing to test, and every change usually waits for a maintenance window.

GKE documentation states the arrangement directly: "Any updates to the Runtime Sensor components are independent of GKE patch version upgrades." The announcement adds that sensor versions and detection rules published by Wiz roll out without GKE version bumps, node pool recreation or workload disruption.

That independence cuts both ways, and a platform team should decide which way it wants before enabling anything. A detection engine that updates on the vendor's schedule keeps pace with new attack behaviour. It also changes what runs on your nodes outside your release calendar, which is a governance question for a regulated environment.

Netics editorial visual: the split between what the managed add-on now owns and what stays with the platform team.

The Preview Label, the Proxy and the Helm Alternative Are the First Checks

Three details decide whether this is a production option this quarter.

The first is the preview status. GKE documentation places the feature under the Pre-GA terms of service, which means the usual "available as is" language and limited support commitments. A regulated workload can wait, and the wait is cheap because nothing forces an early decision.

The second is egress design. A sensor that cannot reach Wiz reports nothing, so the proxy configuration is part of the architecture and belongs in the firewall request early. The third is the install path. The Helm chart remains available, offers more configuration freedom, and leaves the components unmanaged by GKE, with issues reported to Wiz. Choose per estate: the add-on for fleet coverage, the chart for clusters that need tuning.

Consider a hypothetical case. Imagine a Paris platform team running forty clusters across three environments and two cloud projects. The add-on plus one organization constraint covers the fleet in a week, and the two clusters running bespoke networking stay on the chart.

Netics editorial visual: the preview status, the egress path and the install path, the three checks that come before any rollout.

Where Runtime Coverage Fits Beside the Configuration Review

Runtime detection complements the controls that decide what a workload may do before it starts. Admission policies, least-privilege service accounts, network rules and the sensor work together to record configured boundaries and activity inside them.

The add-on makes that layer cheaper to run, and the enforcement constraint makes it harder to forget. Both are good news for a small platform team that has been maintaining three copies of an agent across a growing fleet.

The open question is what the platform team gives up in exchange for the managed lifecycle: a vendor-owned update channel on every node, and a detection engine that lives outside the cluster's own release process. That trade is reasonable for most estates, and it deserves an explicit answer taken on purpose. This level of hardening belongs in security audit and hardening work, and the credential-handling argument connects to the earlier analysis of hardening a Fortinet estate with AI assistance.

Originally published on the Netics blog.

GitHub Actions Down Again? How to Mirror Your Repos to Codeberg Without Actions

Alan West — Sat, 31 Oct 2026 19:00:00 +0000

On October 30 at 17:50 UTC, GitHub started investigating degraded performance for Actions and Webhooks. Ten minutes later Pages was on the list too. By 18:06 they were reporting delayed workflows, delayed Pages deployments, delayed webhook events, and errors in code search and live updates. The incident was marked resolved at 19:23.

That's about 90 minutes on the status page. In the Hacker News thread, one commenter pointed out that the same incident happened 11 days earlier, and another counted "several Actions outages in the past two weeks."

The same day, Tangled published The federated code forge, arguing that relying on someone else for your uptime "hasn't played out well." I don't think the timing was planned. It still works as an ad.

My take: don't move everything off GitHub because of one bad Friday afternoon. Spend an hour this week mirroring your repos to Codeberg, a self-hosted Forgejo or Tangled, so the next outage costs you 10 minutes instead of a lost evening. Below: a status check you can alias, four ways to mirror, the popular setup that fails during an outage, and a CI fallback.

Step 0: check if GitHub is down before you debug your own pipeline

I've seen people (fine, I've been one of them) rerun a stuck workflow four times, roll back a commit and blame a Dependabot bump before checking whether GitHub itself is broken. GitHub's status page has a public JSON API, so make the check a shell alias:

alias ghdown='curl -s https://www.githubstatus.com/api/v2/components.json \
  | jq -r ".components[] | select(.status != \"operational\") | \"\(.name): \(.status)\""'

If that prints Actions: degraded_performance, close the laptop. To list active incidents, use https://www.githubstatus.com/api/v2/incidents/unresolved.json. The full endpoint list also covers summary, scheduled maintenance and incident history.

One caveat from the HN thread: people noticed the 30-day uptime bar staying green during acknowledged incidents, because partial degradation isn't counted as downtime. One commenter mentioned that a third-party status page had to be built to track Actions accurately. So a green bar on the status page tells you very little.

The trap: mirroring GitHub with a GitHub Action

The most common mirror setup I see is a workflow that runs git push --mirror to Codeberg on every push. It works fine until Actions goes down, and then the mirror stops updating at exactly the moment you need it.

Your mirror has to be updated by something that doesn't depend on GitHub's job queue. That leaves two options: your own machine, or a forge that pushes or pulls on its own schedule.

Option 1: one `git push`, two forges

This is the cheapest setup and needs no infrastructure. Git lets one remote have several push URLs:

# keep fetching from GitHub, but push everywhere
git remote set-url --add --push origin git@github.com:you/project.git
git remote set-url --add --push origin git@codeberg.org:you/project.git
git remote set-url --add --push origin git@tangled.org:you.tngl.sh/project

git remote -v
# origin  git@github.com:you/project.git (fetch)
# origin  git@github.com:you/project.git (push)
# origin  git@codeberg.org:you/project.git (push)
# origin  git@tangled.org:you.tngl.sh/project (push)

The first --add --push replaces the implicit push URL, which is why GitHub has to be listed explicitly. From then on, every git push goes to all three. You need to create the empty repos on Codeberg and Tangled first.

The weakness is that it only mirrors what you push from that clone. Merges done through the GitHub UI won't show up until someone pulls and pushes again. For a solo project that's fine. For a team, use option 3.

Option 2: Codeberg, which only takes pushed mirrors

Codeberg runs Forgejo, and Forgejo supports pull mirrors. Codeberg.org doesn't allow them, though. Their FAQ says that "mirrors that pull content from other code hosting services were problematic for Codeberg" and suggests manual mirrors with multiple remotes and git push --mirror instead (FAQ). That's option 1 again, and I think it's a reasonable rule for a nonprofit that pays for its own disks.

If the Codeberg copy is a backup and nothing more, turn off issues and PRs in the repo settings so nobody files bugs in the wrong place.

Option 3: self-hosted Forgejo pull mirror, then fan out

If you have a $5 VPS or a homelab box, this is the setup I'd pick, because it's the only one here that catches merges done in the GitHub UI. On your own Forgejo instance, create the repo with New Migration and check This repository will be a mirror. Forgejo then pulls from GitHub on a schedule, including changes made through the GitHub web UI.

You can then fan out from there: Settings > Repository > Mirror Settings > Add Push Mirror pushes to Codeberg, Tangled or GitLab. For GitLab, the Forgejo docs say to use oauth2 as the username and a token with the write_repository scope. SSH push mirrors generate an Ed25519 key that you add as a deploy key on the target.

Two warnings from those docs: push mirrors are forced and overwrite the remote, and LFS over SSH isn't implemented, so an SSH push mirror won't carry your LFS objects.

Option 4: Tangled, the federated forge on ATProto

Tangled is built on the AT Protocol, the same protocol Bluesky runs on. Repos live on "knots," which you can host yourself or leave on tangled.org. CI runs on "spindles." The October 30 release added knot2, a Rust rewrite of the knot server, and moved issues, PRs, comments, reactions and labels onto the knot as collaborative objects, each one "just a chain of Git objects in the repo itself." That matters for mirroring: if your knot holds the issues too, your backup carries the issue and PR discussion along with the commits. The blog's pitch is "Whatever you choose, you can still talk to everyone else."

Pushing to it is plain SSH. Add your key under Settings > Keys, then:

Host tangled.org
  Hostname tangled.org
  User git
  IdentityFile ~/.ssh/id_ed25519
  AddressFamily inet

For a backup, the gaps count for more than the features:

Private repos aren't available yet. A co-founder said on HN they're rolling out "in the following couple weeks," and another team member said they have a working demo. Until they ship, Tangled only works for public code.
HTTPS push and clone came up because people want knots behind Cloudflare. A team member replied that HTTPS push already works but isn't documented yet, so expect to figure it out yourself.
On Windows, one commenter couldn't clone a repo with a colon in a filename. That's a Windows limit, not a Tangled bug, but it'll bite you the same way.
Self-hosted knot operators have to upgrade to v1.20.0 for the new release.

Most of that thread is an argument about the protocol. One camp says ATProto "heavily lends itself to centralization." The other camp says relays are cheap and that ForgeFed, the ActivityPub approach Forgejo was working on, has been "in limbo forever." I lean toward Tangled here, but for a reason other than the protocol. A federated forge that ships stacked PRs today is more useful than a theoretically better protocol that hasn't shipped. Still, I wouldn't make a forge without private repos my only backup.

The CI fallback: Forgejo Actions, Woodpecker or Tangled spindles

A mirror with no CI is a read-only archive. You don't need to port your whole pipeline, just enough to run tests and cut a release by hand.

	Where it runs	Config	Notes
Forgejo Actions	Your runner, or Codeberg's limited hosted Actions	`.forgejo/workflows/*.yml`	Designed to feel familiar to GitHub Actions users, though not compatible; disabled by default per repo on Codeberg
Woodpecker CI	Codeberg's hosted instance (request access) or self-hosted	`.woodpecker.yml`	What Codeberg's docs recommend for hosted CI
Tangled spindles	Self-hosted runner, or third-party CI via tack	`.tangled/workflows/*.yml`	Nixery engine, deps from Nixpkgs

A minimal spindle workflow looks like this. The pipeline docs list push, pull_request and manual as events, and nixery as the only engine for now:

when:
  - event: ["push", "pull_request"]
    branch: ["main"]

engine: "nixery"

dependencies:
  nixpkgs:
    - go

steps:
  - name: test
    command: "go test ./..."

The useful part of the Forgejo runner is that it connects outbound to the forge, so a box behind NAT works. Codeberg's docs say it "does not need a public IP address." An old laptop in a closet is enough to unblock a hotfix.

The one-hour checklist

Add the ghdown alias, or a bookmark to https://www.githubstatus.com/api/v2/summary.json.
Create empty repos on Codeberg and/or Tangled.
Add them as extra push URLs on origin, or set up a pull mirror on your own Forgejo.
Make sure the mirror doesn't depend on GitHub Actions.
Copy your test job to one fallback CI and run it once, so you know it works before you need it.
Write down which secrets the release job needs and where they'd live on the backup forge.

I'm not leaving GitHub. It's still where people find your project, and it will probably stay that way. I just want "GitHub is down" to mean I push somewhere else for 90 minutes and keep working.

So: do you keep a mirror of your repos anywhere besides GitHub, or are you all in? And if you've tried Tangled's ATProto setup, is it federation or a nicer-looking single point of failure?

Sources

Claude MCP Server Connection Timeouts: Fixing the 30,000ms Startup Limit

The Dollar Craft — Sat, 31 Oct 2026 19:00:00 +0000

If you run Claude Desktop with Model Context Protocol servers under heavy production loads, you hit a silent wall. Operations freeze, background jobs drop, and connections fail with cryptic errors.

The issue is not your database or server logic. It is a hardcoded default inside Claude Desktop. The application enforces a strict 30,000 millisecond timeout for startup handshakes.

When an MCP server takes longer than 30 seconds to boot, initialize dependencies, or parse configuration files, Claude terminates the process.

Here is the technical walkthrough, architectural breakdown, and code fixes to eliminate these connection timeouts.

The 30,000ms Bottleneck: Why Claude MCP Drops Long-Running Connections

MCP does not run like standard HTTP APIs. It relies on persistent STDIO or SSE channels to pass tools and prompts between the client and local processes.

Default Handshake Limits in Claude Desktop

Claude Desktop allocates 30 seconds for the initial connection handshake. During this window, your server must initialize stdout and stdin channels, respond to the initialize JSON-RPC method call, and return available capabilities.

If your script performs database connection pooling, fetches remote secrets, or loads heavy libraries during startup, it hits the timeout limit.

Step-by-Step Fix: Overriding Default Timeout Settings

Method 1: Modifying Environment Variables in claude_desktop_config.json

To override connection timeout thresholds, pass explicit environment variables directly within your JSON configuration file.

Open your claude_desktop_config.json file located at APPDATA\Claude\claude_desktop_config.json on Windows or Library/Application Support/Claude/claude_desktop_config.json on macOS.

Add scoped server timeouts directly inside the env object:

{
"mcpServers": {
"production-data-ingest": {
"command": "node",
"args": ["C:/mcp-servers/data-ingest/dist/server.js"],
"env": {
"MCP_TIMEOUT_MS": "120000",
"NODE_OPTIONS": "--max-old-space-size=4096"
}
}
}
}

Method 2: Adjusting Client-Side Call Parameters in Python

If you invoke MCP servers programmatically using Python, the default ClientSession timeout drops long-running tool executions. Pass explicit timedelta values to read_timeout_seconds when initializing the session.

import asyncio
from datetime import timedelta
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

server_params = StdioServerParameters(
command="python",
args=["heavy_worker.py"]
)

async def run_pipeline():
async with stdio_client(server_params) as (read, write):
async with ClientSession(
read,
write,
read_timeout_seconds=timedelta(seconds=120)
) as session:
await session.initialize()

        result = await session.call_tool(
            "process_large_dataset",
            arguments={"batch_size": 5000},
            read_timeout_seconds=timedelta(seconds=180)
        )
        print(result)

if name == "main":
asyncio.run(run_pipeline())

Advanced Engineering Fixes for Production Pipelines

Implementing Asynchronous Handshakes and Exponential Backoff

In distributed production setups, immediate retries cause thundering herd problems when an MCP server experiences latency. Implement asynchronous backoff loops with random jitter.

import asyncio
import random
import logging
from datetime import timedelta
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
from mcp.shared.exceptions import McpError

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("mcp-resilience")

async def connect_with_retry(max_retries=5, base_delay=2.0):
server_params = StdioServerParameters(
command="node",
args=["dist/index.js"]
)

for attempt in range(max_retries):

    try:

        async with stdio_client(server_params) as (read, write):

            async with ClientSession(

                read, 

                write, 

                read_timeout_seconds=timedelta(seconds=90)

            ) as session:

                await session.initialize()

                logger.info("Successfully established MCP session.")

                return session

    except (McpError, ConnectionError, TimeoutError) as err:

        if attempt == max_retries - 1:

            logger.error("Max connection attempts reached.")

            raise err

    sleep_duration = (base_delay ** attempt) + random.uniform(0.1, 0.5)
    logger.warning(f"Attempt failed: {err}. Retrying in {sleep_duration:.2f}s...")
    await asyncio.sleep(sleep_duration)

Final Technical Takeaways

Startup handshakes and tool executions fail for different architectural reasons. Fix the startup routine first.

Never run database schema migrations or heavy library imports during the initial process boot sequence.

Always use absolute paths when targeting runtimes like node or python on Windows platforms.

Implement client-side exponential backoff loops to recover from transient connection drops gracefully.

🚹Author Bio:
The Dollar Craft is an independent AI research publication documenting B2B automation architectures, private local RAG deployments, and no-code data infrastructure for legal and financial firms across North America and Europe. We specialize in analyzing compliance-first AI integrations, self-hosted n8n workflows, and data-backed systems for modern enterprises.

⚖️> Disclaimer: This article is for educational and informational purposes only. The views expressed are my own and do not reflect the official stance of any vendor or tool mentioned. Test all configurations and scripts in a staging environment before running them in production.

Software Supply Chain Security for Small Teams

Norbert E. Boros — Sat, 31 Oct 2026 19:00:00 +0000

Supply chain security sounds like a problem for organisations with a security function, and the framing is misleading. A small team running a handful of services typically depends on hundreds of packages it has never read, pulled at build time from registries it does not control, executing installation scripts on machines that hold its deployment credentials.

The exposure is not proportional to company size. It is proportional to dependency count and build automation, and small teams often have more of the first and less scrutiny of the second than the organisations that worry about this publicly.

The uncomfortable arithmetic: your application has perhaps a dozen direct dependencies and several hundred transitive ones. You chose the dozen. You did not choose the rest, you have not read any of them, and any one of them running an install script has the same access as your build process. That is the actual attack surface, and it is not visible from the dependency list you wrote.

Supply Chain Security Starts at Install Time

The dangerous moment is usually not running the code. It is installing it.

Package managers permit scripts to execute during installation, which means a compromised or malicious package runs with the privileges of whoever ran the install. On a developer machine that is their credentials. In a build pipeline it is the deployment keys, which is worse.

Three attack shapes account for most real incidents.

Typosquatting. A package with a name one character from a popular one, published and waiting for a mistyped install command. Cheap to execute and effective at scale.

Account compromise of a legitimate package. A widely used package whose maintainer's credentials were stolen, updated with something harmful. This is the hardest to defend against because nothing about the name or the download count looks wrong.

Dependency confusion. A public package published under the name of one of your internal ones, where a misconfigured resolver prefers the public registry. Entirely a configuration problem and entirely preventable.

None of these require anyone to target you specifically, which is the point. They are opportunistic and they scale.

Controls That Repay the Effort at Small Scale

Commit the lockfile and install from it. A lockfile pins exact versions and their hashes. Installing from the manifest instead resolves fresh versions at build time, which means your build is not reproducible and an upstream change reaches production without review. Use the install command that fails when the lockfile disagrees rather than the one that updates it.

Disable install scripts where you can. Many ecosystems support this, and most packages do not need them. It is the single largest reduction in exposure available, and the packages that break are worth knowing about.

Automate vulnerability alerts, then triage. Scanners produce more findings than a small team can act on, and the failure mode is not missing alerts, it is ignoring all of them because most are irrelevant. Filter to what is reachable from your code and act on that. A queue nobody reads is worse than no queue.

Pin your build tooling too. The container image, the runtime version and the action or plugin your pipeline calls are all dependencies, and referencing a mutable tag means your build changes without you.

Separate build credentials from everything else. A pipeline that can deploy should not hold credentials that can do anything more, and a compromised build should not be able to reach production data.

What an SBOM Does and Does Not Tell You

A software bill of materials lists what is in your application, and its value is answering one question fast: are we affected by this?

That question used to take days. When a widely used component turns out to be vulnerable, an organisation with a current inventory answers in minutes and one without it spends a week searching. That difference is the whole argument, and it is why SBOM adoption is being pushed as baseline practice rather than as an advanced control.

What it does not do is make you secure. An inventory is a list, not a defence. It does not tell you whether a listed vulnerability is reachable in your code, whether it matters in your configuration, or whether anything has been compromised. Teams that generate one and file it have added a document rather than a control.

Generate it from the build, so it describes what was actually shipped rather than what the manifest claimed. Keep the one matching each release. And accept that its value is entirely in the speed of answering a question you will be asked under pressure.

Where Small Teams Actually Get Hurt

Not usually by an exotic package compromise. By ordinary things.

Secrets in the repository, which remain in history after deletion and are found by automated scanners within minutes of a push. A dependency three years out of date with a published exploit and no upgrade path, because upgrading was deferred until it became a project. Build pipelines with excessive permissions, where a pull request from a fork can run with access it should not have. Nobody watching, so a compromise persists because no alert reaches a person.

The unglamorous conclusion is that keeping dependencies current is most of supply chain security in practice. The software maintenance cost that teams treat as optional is the same work, and deferring it converts a routine upgrade into an emergency with an exploit attached.

A Proportionate Starting Point

For a small team, in order: get secrets out of the repository and rotate anything exposed. Commit lockfiles and install from them strictly. Turn on dependency alerts and triage weekly rather than continuously. Pin build tooling to immutable references. Reduce pipeline permissions to the minimum. Generate an SBOM per release once the rest is in place.

That sequence covers the realistic threats without a security function, and each step is hours rather than weeks. The controls beyond it, provenance attestation, reproducible builds, signed artefacts, are genuinely valuable and belong to a stage where the basics are already stable.

Mecanik reviews and hardens build pipelines as part of our application security work. The finding is almost never a sophisticated compromise. It is a token in a repository and a dependency nobody has updated since it was chosen.

Related reading

Frequently Asked Questions

Why is installing packages the risky moment?
Because package managers allow scripts to run during installation, with the privileges of whoever ran the install. On a developer machine that means their credentials; in a build pipeline it means deployment keys. The code does not have to be executed by your application to do damage.

What is dependency confusion?
An attack where a public package is published under the name of one of your internal packages, and a misconfigured resolver prefers the public registry over your private one. It requires nobody to target you specifically and is entirely preventable through resolver configuration.

What does an SBOM actually give you?
A fast answer to one question: are we affected by this? With a current inventory that takes minutes; without one it takes a week of searching. It does not tell you whether a listed vulnerability is reachable in your code or whether anything has been compromised, so an SBOM that is generated and filed is a document rather than a control.

Should I commit my lockfile?
Yes, and install from it strictly using the command that fails when the lockfile disagrees rather than the one that updates it. Installing from the manifest resolves fresh versions at build time, which makes builds unreproducible and lets an upstream change reach production without any review.

Where should a small team start?
Remove secrets from the repository and rotate anything exposed, commit lockfiles and install strictly, enable dependency alerts and triage them weekly, pin build tooling to immutable references, reduce pipeline permissions, then generate an SBOM per release. Each step is hours rather than weeks.

Building hldays #7: Religious and cultural observances

Alexander Denisov — Sat, 31 Oct 2026 19:00:00 +0000

A public holiday is a legal fact: the law says the office is closed. A religious observance is something else. Ramadan, Passover or Lunar New Year don't close anything in Lisbon, but a lot of people still plan around them: shift rotas, delivery windows, a marketing calendar, a meeting you shouldn't put on Yom Kippur.

So hldays has a second layer next to holidays: observances. There are 46 of them across six traditions (Western Christian, Orthodox Christian, Jewish, Islamic, Chinese and Buddhist), served by /v1/observances and attached to the date endpoints on paid plans.

I added them for exactly that kind of scheduling. The API already knew when offices close, and it felt incomplete not to know when a lot of people are busy anyway.

This post is mostly about the calendars, because that's where the interesting problems were.

Data first

Each tradition is one YAML file in data/observances/. An observance looks a lot like a holiday rule, with three extra ideas: a span (days or an end rule), an evening start (eve), and whether the date is a calculation that might be off (estimated):

- id: passover
  name: { en: "Passover", he: "פסח" }
  rule: { calendar_date: { calendar: hebrew, month: Nisan, day: 15 } }
  days: 8
  eve: true
  notes: "8 days in the diaspora, 7 in Israel."

The rule kinds are the same ones the holiday engine uses (src/core/dates.ts), so an observance can be a fixed date, an offset from Easter, an offset from Orthodox Easter, or a day in another calendar.

Easter: the one with an algorithm

Western Easter is the anonymous Gregorian algorithm, straight from the textbook:

/** Gregorian Easter Sunday (anonymous Gregorian algorithm). */
export function easterSunday(year: number): Date {
  const a = year % 19;
  const b = Math.floor(year / 100);
  const c = year % 100;
  // ... eleven more lines of integer arithmetic
  const month = Math.floor((h + l - 7 * m + 114) / 31);
  const day = ((h + l - 7 * m + 114) % 31) + 1;
  return new Date(Date.UTC(year, month - 1, day));
}

Everything movable in the Western calendar is an offset from it: Ash Wednesday is { easter: -46 }, Pentecost { easter: 49 }. The same function already drives holidays like Good Friday and Corpus Christi in the national data, so observances got it for free.

Orthodox Easter: same idea, different calendar

Orthodox churches compute Easter on the Julian calendar. The code uses Meeus' Julian algorithm and then shifts the result onto the Gregorian calendar:

/** Orthodox Easter Sunday as a Gregorian date (Meeus' Julian algorithm + Julian→Gregorian shift; valid 1900–2099). */
export function orthodoxEasterSunday(year: number): Date {
  const a = year % 4;
  const b = year % 7;
  const c = year % 19;
  const d = (19 * c + 15) % 30;
  const e = (2 * a + 4 * b - d + 34) % 7;
  const month = Math.floor((d + e + 114) / 31);
  const day = ((d + e + 114) % 31) + 1;
  const shift = Math.floor(year / 100) - Math.floor(year / 400) - 2; // 13 days in 1900–2099
  return addDays(new Date(Date.UTC(year, month - 1, day)), shift);
}

The shift line is the bit worth noticing: the gap between the two calendars grows by a day in most century years, and it's 13 days for the whole range hldays supports (2016 to 2099). The test includes the year both Easters coincide, which is a good sanity check:

expect(formatDate(orthodoxEasterSunday(2025))).toBe("2025-04-20"); // same day as Western Easter
expect(formatDate(orthodoxEasterSunday(2026))).toBe("2026-04-12");
expect(expandRule({ orthodox_easter: -48 }, 2026)).toEqual(["2026-02-23"]); // Greek Clean Monday

The YAML also notes a split inside Orthodoxy: Julian-calendar churches celebrate Christmas on 7 January, while Revised Julian churches (Greek, Romanian, Bulgarian) use 25 December but share the Orthodox Easter cycle. That's a note on the record, not two records.

Hebrew and Islamic dates: let Intl do it

I didn't want to ship conversion tables for every calendar. JavaScript's Intl.DateTimeFormat already knows the Hebrew and Islamic calendars (through ICU), so the engine builds an index for a Gregorian year by formatting every day of it:

fmt = new Intl.DateTimeFormat(`en-u-ca-${calendar}`, { timeZone: "UTC", month: "numeric", day: "numeric" });
// Intl silently falls back to Gregorian when a runtime lacks the calendar; wrong dates are worse than an error.
if (fmt.resolvedOptions().calendar !== calendar) throw new Error(`Intl calendar ${calendar} is not supported`);

That second line is my favourite in the file. If a runtime doesn't support a calendar, Intl doesn't throw: it quietly formats Gregorian dates instead. Without the check, a runtime without full ICU would treat Islamic month 10, day 1 as 1 October and put Eid al-Fitr there. I checked that the output on Cloudflare Workers matches Node before relying on it.

The Hebrew calendar had one naming trap. In leap years there are two Adars, and Intl calls the second one "Adar II". Purim is in Adar II in leap years, so the index stores "Adar II" under "Adar":

const month = parts.find((p) => p.type === "month")!.value.replace(/^Adar II$/, "Adar");


// "Adar" is Adar II in leap years (Purim)
expect(expandRule(purim, 2024)).toEqual(["2024-03-24"]);
expect(expandRule(purim, 2025)).toEqual(["2025-03-14"]);

Islamic dates are estimates, and the API says so

The Islamic calendar is lunar, and in many countries a month starts when the new moon is actually sighted. No algorithm can know that in advance. hldays calculates with the Umm al-Qura calendar (Saudi Arabia's), and the YAML says up front what that means:

# Islamic observances, calculated with the Umm al-Qura calendar (Saudi Arabia). Many countries start months on
# a local moon sighting, so the observed date can differ by a day: every entry is marked estimated.

Every Islamic observance has estimated: true, and it comes through in the response so clients can show "around" instead of a firm date. Here's Eid al-Fitr on a business-day call (paid plan, run locally):

{
  "jurisdiction": { "id": "PT-M-1106", "name": "Lisboa", ... },
  "date": "2026-03-20",
  "business_day": true,
  "holidays": [],
  "observances": [
    { "observance_id": "eid-al-fitr", "tradition": "islamic", "name": { "en": "Eid al-Fitr", "ar": "عيد الفطر" },
      "start": "2026-03-20", "end": "2026-03-22", "starts_previous_evening": true, "estimated": true }
  ]
}

starts_previous_evening comes from eve: true: Jewish and Islamic days begin at sunset, so Eid "on" 20 March starts on the evening of the 19th.

A lunar year is about 11 days shorter than a Gregorian one, which breaks a quiet assumption: that a date happens once a year. Eid al-Fitr happens twice in 2033. The rule expander returns a list for that reason, and the test makes it explicit:

// The Islamic year is ~11 days shorter, so some Gregorian years hold the same date twice
expect(expandRule(eid, 2033)).toHaveLength(2);

Spans that cross New Year

Ramadan doesn't have a fixed length: it's 29 or 30 days. So instead of days, it has an end rule: the day before 1 Shawwal.

- id: ramadan
  rule: { calendar_date: { calendar: islamic-umalqura, month: 9, day: 1 } }
  end: { calendar_date: { calendar: islamic-umalqura, month: 10, day: 1, offset: -1 } }

Around 2030 Ramadan starts in December and ends in January. Asking "what's observed on 5 January 2031?" has to find a span that started the previous year, so Observances.between always looks one year back:

// A span can start in the previous Gregorian year (Ramadan across New Year).
for (let y = Number(from.slice(0, 4)) - 1; y <= Number(to.slice(0, 4)); y++) {


{ "date": "2031-01-05", "data": [{ "observance_id": "ramadan", "start": "2030-12-26", "end": "2031-01-23", "estimated": true, ... }] }

The Chinese calendar: where Intl was wrong

I started with Intl for the Chinese calendar too. Then I compared it with the Hong Kong Observatory's published tables and found that ICU gets 5 of the 1039 month starts between 2016 and 2099 wrong by a day. Two of them are Chinese New Year: 2027 and 2030.

You can see it in Node (ICU 78.3):

2027-02-06 12/30 <- ICU: last day of the 12th month
2027-02-07 1/1 <- ICU: New Year
2030-02-02 1/1 <- ICU: New Year

The HKO tables say 6 February 2027 and 3 February 2030. Being a day off on the biggest date in the calendar wasn't acceptable, so for the Chinese calendar only, hldays uses HKO's data. scripts/import-chinese-calendar.ts downloads one text file per year and keeps just the month starts:

const m = /^(\d{4})\/(\d{1,2})\/(\d{1,2})\s+(\d{1,2})(?:st|nd|rd|th) Lunar Month/.exec(line);
if (!m) continue;
const month = Number(m[4]);
// HKO repeats the month number for a leap month
const leap = month === prevMonth;
starts.push(`${m[1]}-${m[2].padStart(2, "0")}-${m[3].padStart(2, "0")} ${month}${leap ? "L" : ""}`);

The result is src/core/chinese-months.json: 1077 entries like "2014-01-31 1", from 2014 to 2100. Leap months are marked L and never match a rule, so "2nd month, day 1" in 2023 is the regular second month and not the leap one that follows it. The tests check the exact days ICU gets wrong:

// 2027 and 2030 are days ICU's Chinese calendar gets wrong; the engine uses the HKO table
expect([2025, 2026, 2027, 2030].flatMap((y) => expandRule(lny, y))).toEqual(["2025-01-29", "2026-02-17", "2027-02-06", "2030-02-03"]);

The table starts in 2014, not 2016, and git history explains why. The first version guarded the range strictly and rejected 2014, but /v1/observances?year=2016 needs it: observances always look one year back (for spans like Ramadan), and Lunar New Year's Eve is "1st month, day 1, offset -1", where an offset makes the engine expand the neighbouring years too. 2016 reaches 2015, and 2015 reaches 2014. A test now asks for the first and last day of the supported range, so that can't come back.

Observances never affect business days

This was a design rule from the first commit of the feature: observances are information, not days off. The business-day code doesn't read them at all. isBusinessDay looks at the weekend and at holidays, and observances are attached to the response afterwards:

const result = calendar.isBusinessDay(j, d, types(c), municipal);
return c.json({
  jurisdiction: summary(j),
  date: d,
  ...result,
  holidays: withSources(c)(result.holidays),
  ...observancesOn(c, d),
  ...
});

Where an observance is a day off, like Good Friday in Portugal, it's also a holiday in that country's data, with a source. The observance list just tells you it's Good Friday; the holiday list tells you the office is closed. Mixing the two would mean Eid closes Lisbon, which it doesn't.

Plans and limits

Observances are on the paid plans only. On the free plan, /v1/observances returns 403 paid_plan_required, and the date endpoints return observances: [] with an observances_notice that says how many were hidden, so a free client still knows something is there.

What isn't covered yet:

Theravada Vesak. The Buddhist file has only the East Asian Buddha's Birthday; Vesak needs a lunar calendar the engine doesn't support.
Hindu and Sikh calendars. Nothing yet.
Regional variants. Jewish festivals use diaspora lengths (Israel's are in notes), Shia dates for Mawlid are a note, and Korea and Vietnam can differ from China by a day where their time zone does.

Which calendar would you want next: Hindu, Vesak, or something else? Tell me in the comments.

Next in the series: making an API agent-friendly with MCP, and designing tools for Claude and other agents.

hldays.dev · Docs

CDC Schema Changes: What Breaks and How to Ship Them

Pipeline Whiteboard — Sat, 31 Oct 2026 18:58:27 +0000

On Friday at 17:40, someone renamed one column in the orders table. The pipeline stayed green all weekend. On Monday, the revenue dashboard showed zero for Saturday and Sunday. Nothing failed, and that was the problem.

This is Part 5 of CDC in Production. In Part 4 the sink learned to survive duplicates, late events and deletes. This time the table itself changes. We'll follow a schema change through the pipeline, look at the registry rules that decide what's allowed, see what Snowflake and the lakehouse can absorb, and finish with a migration pattern that never breaks either side.

Prefer to watch? Here's the 7-minute video version with animated diagrams:

Video link: CDC Schema Changes: What Breaks and How to Ship Them

How a schema change travels

Postgres logical decoding (the feature that turns the write-ahead log into row changes) doesn't carry DDL. So Debezium never sees the ALTER TABLE itself. It notices the new shape on the next row change for that table and refreshes its in-memory schema. That event goes out with the new structure.

If you use Avro, the converter then registers the new structure as a new schema version in Schema Registry, a service that stores every version of each message schema. Versions are grouped under a subject; with the default naming, the value schema for topic shop.public.orders lives under shop.public.orders-value. Before accepting a new version, the registry runs a compatibility check against what's already there.

The converter is configured on the connector (or the Connect worker):

"value.converter": "io.confluent.connect.avro.AvroConverter",
"value.converter.schema.registry.url": "http://schema-registry:8081"

Registry compatibility modes

Compatibility is the rule the registry uses to decide whether a new version may be registered. The default is BACKWARD.

Mode	Guarantee	Upgrade first
`BACKWARD` (default)	Consumers using the new schema can read data written with the old one	Consumers
`FORWARD`	Consumers using the old schema can read data written with the new one	Producers
`FULL`	Both directions	Either side, independently

By default the check compares only against the latest version. The _TRANSITIVE variants (BACKWARD_TRANSITIVE and so on) compare against every version, which matters if a consumer might replay old data from the start of a topic.

What does that allow in practice, with Avro?

Change	`BACKWARD`	`FORWARD`	`FULL`
Add an optional field (has a default)	✅	✅	✅
Remove an optional field	✅	✅	✅
Add a required field (no default)	❌	✅	❌
Remove a required field	✅	❌	❌

All of it comes from one rule in Avro's schema resolution: if the reader's schema has a field with no default, and the data was written without that field, the read fails. With Debezium, a nullable Postgres column becomes an optional field with a null default. A NOT NULL column becomes a required field, unless Debezium can carry the column's default value into the schema (it does this for many defaults; for function defaults, see mistake 4 below).

The rename, two ways

amount_cents became total_cents. To Debezium, that's one field gone and a new one added.

If the column is NOT NULL, the new field is required, with no default. Under BACKWARD, the registry rejects it. The converter throws, and with Kafka Connect's default errors.tolerance=none, the connector task fails. That's loud, and loud is good: someone gets paged on Friday.

In the real incident, the column was nullable. Both fields are optional, so the registry accepts the change and nothing turns red. Snowflake, with schema evolution switched on, adds a TOTAL_CENTS column. The old AMOUNT_CENTS column gets NULL on every new row. Every dashboard still sums AMOUNT_CENTS, so weekend revenue reads zero.

A failed connector is the good outcome. The dangerous schema changes are the ones every system accepts.

What Snowflake absorbs

Schema evolution lets a load add columns to the target table automatically. It needs three things:

ALTER TABLE analytics.orders SET ENABLE_SCHEMA_EVOLUTION = TRUE;

-- The loading role needs EVOLVE SCHEMA (or OWNERSHIP) on the table
GRANT EVOLVE SCHEMA ON TABLE analytics.orders TO ROLE loader;

and a supported loading method: COPY INTO (with MATCH_BY_COLUMN_NAME), Snowpipe, or Snowpipe Streaming. Plain INSERT can't evolve a table.

And it does only two things:

it adds new columns, and
it drops NOT NULL from columns that are missing in new data.

It never renames and never changes a type.

Type changes through ALTER TABLE ... ALTER COLUMN are stricter still:

Change	Allowed?
Make a `VARCHAR` longer	✅
Raise a number's precision	✅
Change a number's scale	❌
Make a `VARCHAR` shorter	❌
Turn a number into a `VARCHAR`	❌

So if Postgres moves price from numeric(10,2) to numeric(12,4), Snowflake can't follow in place. The scale changed. You add a new column, backfill it, and switch readers over, which is the pattern at the end of this post.

The lakehouse: more forgiving, not magic

Apache Iceberg tracks every column by a unique field ID, not by its name. Renames and drops are metadata changes, so no data files are rewritten. A new column gets a fresh ID, so it never reads old data by mistake, even if it reuses an old name. Type changes are limited to safe widening: int to long, float to double, or a decimal with more precision and the same scale.

Delta Lake can rename and drop columns only with column mapping enabled:

ALTER TABLE orders SET TBLPROPERTIES (
  'delta.columnMapping.mode' = 'name',
  'delta.minReaderVersion'   = '2',
  'delta.minWriterVersion'   = '5'
);

That's a protocol upgrade you can't undo, and after a rename or drop it can break readers of the table's change data feed.

Here's the catch for both formats: a CDC sink still sees a rename as a dropped field and a new one, because that's what the events say. Unless you rename the table column yourself, you get the same split as in Snowflake.

Expand, then contract

The safe pattern is expand/contract: make the schema bigger first, move everything over, and only then make it smaller. A rename becomes four steps:

-- 1. Expand: add the new column as nullable (or with a constant default)
ALTER TABLE orders ADD COLUMN total_cents bigint;

-- 2. Backfill in small batches, and have the application write both columns
UPDATE orders
SET    total_cents = amount_cents
WHERE  total_cents IS NULL
  AND  id BETWEEN 1 AND 50000;

-- 3. Move every reader (views, models, dashboards) to total_cents

-- 4. Contract, weeks later, once nothing reads the old column
ALTER TABLE orders DROP COLUMN amount_cents;

Because amount_cents was nullable, every step only adds or removes an optional field, which the registry accepts in any mode. (Dropping a NOT NULL column removes a required field, which passes BACKWARD but not FORWARD or FULL.) Two practical notes:

The backfill is CDC traffic. Every row it updates becomes a change event, which is why it runs in batches.
Snowflake won't drop the old column for you. Schema evolution never removes columns. Drop AMOUNT_CENTS in the warehouse yourself once readers have moved.

Two guardrails

Test schemas in CI. Schema Registry has a compatibility endpoint that tells you whether a schema would be accepted, without registering it:

# Wrap the new Avro schema in the request body the registry expects
python3 -c 'import json, sys; print(json.dumps({"schema": open(sys.argv[1]).read()}))' \
  orders-value.avsc > payload.json

curl -X POST \
  -H 'Content-Type: application/vnd.schemaregistry.v1+json' \
  --data @payload.json \
  'http://schema-registry:8081/compatibility/subjects/shop.public.orders-value/versions/latest?verbose=true'
# {"is_compatible":false,"messages":[...]}

Fail the build when is_compatible is false. Remember that a nullable rename passes this check, so it catches only the loud kind of break.

Watch the warehouse. Alert when a new column appears on a captured table, and when a column's null rate jumps:

SELECT DATE_TRUNC('hour', updated_at)              AS hour,
       COUNT(*)                                    AS rows_loaded,
       COUNT_IF(amount_cents IS NULL) / COUNT(*)   AS null_rate
FROM   analytics.orders
WHERE  updated_at >= DATEADD(day, -2, CURRENT_TIMESTAMP())
GROUP  BY 1
HAVING null_rate > 0.2
ORDER  BY 1;

The threshold is yours to pick. Either alert would have caught Friday's rename on Friday night.

Five common mistakes

Renaming a column with a single ALTER. Use expand/contract.
Changing a numeric column's scale in place. Snowflake can't follow.
Setting compatibility to NONE just to get a failed connector running again. You've switched off the only alarm.
Trusting function defaults. Debezium exports a default like CURRENT_TIMESTAMP(6) as a zero value (1970-01-01) in the schema.
Changing a schema during an incremental snapshot. The Postgres connector doesn't support it.

Recap

Postgres doesn't send DDL, so the next event carries the new schema.
The registry checks compatibility, BACKWARD by default. Optional fields are safe to add or remove; required fields are not.
Snowflake adds columns, but never renames or changes types.
In the lakehouse, your sink still sees a rename as a drop and an add.
So expand, then contract.

This week, find the last schema change on a captured table and check what it did in the warehouse.

The CDC in Production series

Part 1: Change Data Capture (CDC) Explained (article · video)
Part 2: Debezium Postgres to Kafka: Every Setting Explained (video)
Part 3: The Silent CDC Bug: Data Loss With No Errors (video)
Previous, Part 4: CDC Deletes, Tombstones and the Idempotent MERGE (video)
Part 5: CDC Schema Changes: What Breaks and How to Ship Them (this post · video)
Next, Part 6: Running CDC in Production: The WAL Slot Trap (video, out November 2)

If this was useful, the video version has the animated diagrams for every step: watch it on YouTube. Subscribe to Pipeline Whiteboard for more diagram-first data engineering explainers. Next up, in the final part: the WAL slot trap, lag, heartbeats, alerting and runbooks.

Sentry never ran on my Next.js server, and the dashboard looked fine

Asermu — Sat, 31 Oct 2026 18:57:14 +0000

I run Asermu, a novel-writing app built with Next.js and deployed as a Docker image on Railway. I added Sentry a while ago. The dashboard stayed quiet, and I took that as good news.

It wasn't. Today I found that server-side Sentry had never started in production. Not once.

The clue

I keep a flag-gated test route that reports a test error to Sentry on purpose. On the server runtime it returned:

{ "sent": true, "runtime": "nodejs", "eventId": "309ea78...", "flushOk": false }

captureException happily handed back an event id. But Sentry.flush() returned false, and nothing arrived in Sentry. The same test on the edge runtime returned flushOk: true, and its event showed up in Sentry.

In 90 days, Sentry had received exactly one event: my own edge test. Zero real server errors is not the same as zero errors.

Ruling out the network

My first guess was Railway's outbound network. So I built the app locally with the production DSN:

How I ran the same build	`flushOk`
`next start`	`true`
`.next/standalone/server.js`	`false`

Same build, same env, same machine. Only the server entry point changed.

The cause

The Docker image runs the standalone output (output: "standalone"), which Next.js traces and copies into .next/standalone. Comparing the two folders:

.next/server/instrumentation.js — present
.next/standalone/.next/server/instrumentation.js — missing, along with the chunks it loads, including the one built from sentry.server.config.ts

instrumentation.ts is where register() imports the Sentry server config. With that file missing from the standalone build, register() never runs, Sentry.init() is never called on Node, and:

captureException still returns an event id, but nothing is sent
flush() returns false
onRequestError reports nothing, so unhandled route errors vanish too

Edge was fine because its instrumentation is bundled with the edge/middleware output, which standalone does include.

This was Next.js 16.4.2 with Turbopack and @sentry/nextjs 10.76.2. I haven't checked other versions, or whether it's already a known issue upstream.

The fix

Copy the missing server files into the standalone folder after the build, without overwriting anything Next.js chose to ship, and fail the build if the file is still missing:

RUN npm run build
# Standalone omits server/instrumentation.js and the chunks it loads.
RUN cd .next/server && find . -type f ! -name '*.map' ! -name '*.nft.json' \
    -exec cp -n --parents {} ../standalone/.next/server/ \; \
    && test -f ../standalone/.next/server/instrumentation.js

In a clean build that adds 7 files, about 1.5 MB. The test -f guard matters: if a future Next.js version moves things around, the deploy fails loudly instead of silently shipping without error reporting again.

After deploying, the server test returned flushOk: true, and both a handled error and an unhandled route error showed up in Sentry.

What I'd tell past me

"No errors" is a claim you have to prove. Fire a test error from every runtime (server, edge, browser) after you set up error tracking, and again after big upgrades.
Check Sentry.flush()'s return value in a test route. An event id alone proves nothing.
If you deploy output: "standalone", compare it with next start. Same build, different entry point, different behaviour.

I build Asermu, an offline-first novel-writing app with no AI writing features. I write here about the engineering behind it.

Five failure tests for an AI-assisted website audit

Procora — Sat, 31 Oct 2026 18:56:08 +0000

Disclosure: This article was generated with AI assistance for Procora. The tests below are design examples, not a claim that a particular production system has passed them.

An AI-assisted website audit has two jobs: collect evidence and explain useful next steps. Testing only the happy path makes it easy for missing data to become a confident claim. These five tests focus on that boundary.

1. A failed fetch must not become a missing-title finding

Arrange an HTTP timeout for one URL. The collector should record a collection failure, with the URL and attempt time. The report should say that the page could not be checked. It must not say the title or heading is absent, because no usable HTML was observed.

A separate fixture with a successful HTML response and no title should produce a missing-title finding. These outcomes need different identifiers and display states.

2. An unconnected private source must not show zero traffic

Run a public crawl with no authorised Search Console property. The search-data component should show “Not connected,” not zero clicks or impressions. Then test a connected property whose API request fails: that state should be “Unavailable,” not a successful measurement.

For a successful request, retain the source, property, date range and retrieval time. If a successful response contains no rows, describe the requested period and the provider's response; do not expand it into “this business has no demand.”

3. Unknown evidence references must fail validation

Give the analysis step an evidence set containing E1 and E2. Return a recommendation citing E99. The renderer should reject that reference or mark the recommendation as unsupported. A fluent explanation must not create its own evidence.

Illustrative validation logic:

Build the set of known IDs from collected evidence.
Require each recommendation to cite at least one evidence ID.
Reject any cited ID outside that set.

This check validates the reference, not the truth of the explanation. Also compare quoted observations with the original record and flag assumptions for review.

4. Public sharing must not expose private measurements

Create a public website report and a separate, authorised private workspace. Request the public report while private metrics exist. The public response must exclude those metrics, account identifiers and tokens. Test access control on the server; hiding a card in the browser is insufficient.

5. Screen and PDF must preserve the same limits

Use an audit fixture covering ten sampled pages of a larger website. Confirm that both views identify the sample, collection time and unmeasured areas. If a provider is unavailable, both outputs should retain that status. Exporting should not convert partial coverage into a whole-site claim.

What to assert

For each test, assert both the stored result and the user-facing wording. Keep “observed,” “recommended” and “not measured” separate. Add idempotent retry tests for transient failures so a retry does not duplicate findings or overwrite a successful observation with an unexplained empty state.

A report is useful when a reader can locate the affected page, understand the evidence, assign a fix and verify the outcome. A decorative score cannot substitute for those steps.

Procora offers an AI-assisted website audit for small businesses. Explore the public website audit. This article presents a general testing approach; it is not an independent audit of Procora.

Echoes After Midnight – A Local AI-Powered Horror Story Generator

Shimra Nasardeen — Sat, 31 Oct 2026 18:55:13 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

I built Echoes After Midnight, a local AI-powered horror story generator that transforms users' ideas into spooky stories.
Users can enter a story idea, select a setting, and choose a horror level, such as Mysterious, Medium, Terrifying, or Nightmare. The application then uses an AI language model to generate a horror story based on their selections.
I interpreted the Ghost in the Machine theme by creating an AI-powered storytelling experience where a local language model brings mysterious and frightening stories to life.

Demo

https://drive.google.com/file/d/1E3RNOYrm_-lQ4I5nNaDkIdpoS1bxWPHX/view?usp=sharing

Code

https://github.com/ShimraNazar/EchoesAfterMidnight.git

How I Built It

I developed the application using Python and Flask for the backend, with HTML, CSS, and JavaScript for the frontend.
For AI-powered story generation, I used TinyLlama 1.1B, a lightweight language model running locally through Ollama.
The application sends the user's story idea, selected setting, and horror level to the Ollama API. The model processes the prompt and generates a horror story, which is then displayed on the website.
Technologies used:
Python
Flask
HTML
CSS
JavaScript
Ollama
TinyLlama 1.1B
Requests

Why Does Open Innovation Matter?

Open innovation makes AI development more accessible to students and developers. By using open-source tools and models, I was able to experiment with AI integration and build an application without depending on paid AI APIs.
Using Ollama and TinyLlama also allowed me to explore local AI inference and understand how language models can be integrated into practical applications.
This project gave me an opportunity to learn how different open-source technologies can work together to create something useful and creative.

The Spirit of It

Every horror story begins with an idea, but sometimes the most frightening part is what we cannot see.
With Echoes After Midnight, I wanted to create an experience where users can turn simple ideas into mysterious stories and explore the creative possibilities of AI.
Let the past whisper, and discover what waits after midnight.

How to read passport data with NFC in a Capacitor app

Dzmitry — Sat, 31 Oct 2026 18:53:35 +0000

Suppose you're building a mobile app with a form for passport details. You could ask users to type everything in. Another option is to scan the document and read data from its chip.

In this guide, we'll build that flow in TypeScript:

Scan the MRZ → read the NFC chip → return document data to your app.

We'll use capacitor-id-reader, a plugin I built for this workflow on iOS and Android. You can connect the example to your existing Capacitor UI.

1. Install and configure the plugin

You'll need Capacitor 8, Node.js 22+, and a physical NFC phone running iOS 15+ or Android API 26+. Use a compatible electronic passport or ID card.

npm install capacitor-id-reader
npx cap sync

On iOS, configure your app target:

Enable Near Field Communication Tag Reading, including it in your signing profile.
Add TAG to the com.apple.developer.nfc.readersession.formats entitlement.
Add NFCReaderUsageDescription and NSCameraUsageDescription to Info.plist.
Add A0000002471001 to the com.apple.developer.nfc.readersession.iso7816.select-identifiers array in Info.plist.

On Android, the plugin declares camera and NFC permissions. Enable NFC on the phone; camera permission is requested when scanning.

Check the native setup instructions when configuring your project.

2. Scan the MRZ and read the chip

The MRZ is the machine-readable text printed on the document. It provides the document number, date of birth and expiry date used for chip access.

import { NfcIdReader, parseMrz } from 'capacitor-id-reader';

export async function readPassport(includePhoto = false) {
  const { available, enabled } = await NfcIdReader.isAvailable();

  if (!available) {
    throw new Error('NFC reading is unavailable on this device.');
  }

  if (!enabled) {
    throw new Error('Enable NFC before reading the document.');
  }

  const scan = await NfcIdReader.scanMrz({
    prompt: 'Position the document’s MRZ inside the camera view',
    cancelLabel: 'Go back',
  });

  const accessData = parseMrz(scan.lines);

  if (!accessData) {
    throw new Error('The MRZ could not be parsed. Please scan it again.');
  }

  // Show an instruction to hold the document against the phone.
  if (includePhoto) {
    return NfcIdReader.readDocument({
      ...accessData,
      dataGroups: ['DG1', 'DG2'],
    });
  }

  return NfcIdReader.readDocument(accessData);
}

DG1 contains document details; DG2 contains the face image. The default call reads DG1. Requesting the photo is an explicit choice.

3. Connect the flow to a button

Treat reading as a user action with loading, success and failure states. Add this controller alongside readPassport, and connect its callbacks to your component state:

type PassportData = Awaited<ReturnType<typeof readPassport>>;

let reading = false;

export async function handleReadClick(ui: {
  setBusy: (busy: boolean) => void;
  showDocument: (document: PassportData) => void;
  showError: (message: string) => void;
}) {
  if (reading) return;

  reading = true;
  ui.setBusy(true);

  try {
    const document = await readPassport();
    ui.showDocument(document);
  } catch (error) {
    ui.showError(
      error instanceof Error ? error.message : 'Reading failed. Please retry.',
    );
  } finally {
    reading = false;
    ui.setBusy(false);
  }
}

Disable the button while busy. On success, use showDocument to populate a review screen before the user submits anything.

The catch block is a starting point. For your app's UX, map the exported ENfcIdReaderError codes to appropriate messages, including cancellation and denied camera permission.

4. Optionally display the face image

Call readPassport(true) to request DG2 in the same NFC session. Then prepare a JPEG URL for your image component:

const document = await readPassport(true);
const photo = document.faceImage;

const jpeg = photo?.previewJpegBase64 ?? (
  photo?.mimeType === 'image/jpeg' ? photo.base64 : undefined
);

const photoUrl = jpeg ? `data:image/jpeg;base64,${jpeg}` : undefined;

Bind photoUrl to an image when it exists. A JPEG 2000 original may need a decoder. See the DG2 documentation for platform details and failure behavior.

Before shipping

A successful chip read does not establish document authenticity, ownership or liveness. The plugin does not implement passive authentication or certificate trust validation. Reading data alone must not be treated as verified identity.

Compatibility and validation work remain. Test your exact package version with representative documents on physical devices, including interrupted reads and retries. Review the audit and known limitations, and avoid logging document data or face images.

You now have a camera-to-NFC flow to connect to your document form. Map the returned data to your fields and let the user review it before submission.

The full API, native setup and device-test example are in the capacitor-id-reader repository.

DEV Community

Give each file a clear job in a two-input upload form

Label the role, then the file

Make the selected range visible

Separate selected, uploading, and ready

👻🎬Miedocuentista: a fully local AI that turns your photos into haunted stories, film scripts and novels📜🪶

What I Built

Demo

Code

shristi005 / Miedocuentista

Feed the spirits one frame at a time. They write the film, the script, the novel.

👻 Miedocuentista

Table of contents

How I Built It

Challenges I Hit (and Why I Think They Happen)

Future Improvements

How It Can Be Used

Why Does Open Innovation Matter?

The Spirit of It

Google Cloud Turns the Wiz Runtime Sensor Into a GKE Add-On

TL;DR

A Runtime Sensor Watches What Containers Do at Kernel Level

GKE Installs the Sensor and Pipes Credentials From Secret Manager

One gcloud Flag Enables It on a New or Existing Cluster

An Organization Policy Makes Runtime Coverage a Create-Time Condition

Telemetry Reaches the Wiz Security Graph and Answers a Narrower Question

Independent Updates Keep Detection Rules Ahead of the Cluster Version

The Preview Label, the Proxy and the Helm Alternative Are the First Checks

Where Runtime Coverage Fits Beside the Configuration Review

GitHub Actions Down Again? How to Mirror Your Repos to Codeberg Without Actions

Step 0: check if GitHub is down before you debug your own pipeline

The trap: mirroring GitHub with a GitHub Action

Option 1: one git push, two forges

Option 2: Codeberg, which only takes pushed mirrors

Option 3: self-hosted Forgejo pull mirror, then fan out

Option 4: Tangled, the federated forge on ATProto

The CI fallback: Forgejo Actions, Woodpecker or Tangled spindles

The one-hour checklist

Sources

Claude MCP Server Connection Timeouts: Fixing the 30,000ms Startup Limit

The 30,000ms Bottleneck: Why Claude MCP Drops Long-Running Connections

Default Handshake Limits in Claude Desktop

Step-by-Step Fix: Overriding Default Timeout Settings

Method 1: Modifying Environment Variables in claude_desktop_config.json

Method 2: Adjusting Client-Side Call Parameters in Python

Advanced Engineering Fixes for Production Pipelines

Implementing Asynchronous Handshakes and Exponential Backoff

Final Technical Takeaways

Software Supply Chain Security for Small Teams

Supply Chain Security Starts at Install Time

Controls That Repay the Effort at Small Scale

What an SBOM Does and Does Not Tell You

Where Small Teams Actually Get Hurt

A Proportionate Starting Point

Frequently Asked Questions

Building hldays #7: Religious and cultural observances

Data first

Easter: the one with an algorithm

Orthodox Easter: same idea, different calendar

Hebrew and Islamic dates: let Intl do it

Islamic dates are estimates, and the API says so

Spans that cross New Year

The Chinese calendar: where Intl was wrong

Observances never affect business days

Plans and limits

CDC Schema Changes: What Breaks and How to Ship Them

How a schema change travels

Registry compatibility modes

The rename, two ways

What Snowflake absorbs

The lakehouse: more forgiving, not magic

Expand, then contract

Two guardrails

Five common mistakes

Recap

The CDC in Production series

Sentry never ran on my Next.js server, and the dashboard looked fine

The clue

Ruling out the network

The cause

Option 1: one `git push`, two forges