DEV Community

When to use overflow: clip with overflow-clip-margin (and when not to)

Chris Rodriguez — Sat, 31 Oct 2026 17:55:03 +0000

Goal

Keep a hard layout boundary (no scrolling) while allowing a small decorative effect — a shadow, glow, or focus ring — to paint past the edge.

What to use

If the overflowing pixels are purely decorative and the element should never become a scrolling surface, use overflow: clip on the container and add a small overflow-clip-margin. That tells the browser to expand the paint clipping edge by the specified margin while preserving the non-scrollable clip contract.

Expected behavior

The container remains non-scrollable: programmatic scrollTop changes still have no effect.
Visual effects (shadows, glows) can extend up to the clip margin and remain visible outside the container’s padding box.
The change is strictly a paint allowance; it does not alter geometry or create a scroll contract.

When not to use it

Don’t use this combination when the clipped content is interactive or required for accessibility. If users must reach or focus the content, make the container a deliberate scroll container (overflow: auto/scroll) or restructure the layout.
Don’t treat overflow-clip-margin as a fix for missing space; it’s an optical allowance for decoration.

Limitations

Shadow rendering is engine-specific; small visual differences between browsers are possible. Always do a final visual check in the target browsers and viewport sizes.
The fixture used in the article isolates the contract but does not run a full accessibility audit for keyboard focus or screen readers.

Why run a small test first

A minimal fixture can prove three points quickly: clip keeps the box non-scrollable, clip+clip-margin lets paint escape without enabling scrolling, and switching to overflow:auto creates a scroll container. Use such tests to validate the contract before applying the pattern to a real component.

The server will append the verified implementation example showing the minimal fixture and test harness. Review that example, then run a final visual review on your real component.

Working example

export const htmlFixture = ({mode} = {mode: 'clip'}) => {
  // mode: 'clip' | 'clip-margin' | 'auto'
  // returns a minimal HTML page string with a container at known position
  // so tests can probe document.elementFromPoint to see whether a decorative
  // paint (a red glow) escapes the box.
  const overflow = mode === 'auto' ? 'auto' : 'clip';
  const clipMargin = mode === 'clip-margin' ? '20px' : '0px';

  // In some Chromium builds the overflow-clip-margin feature may not be
  // implemented, which would make tests that rely on purely painted shadows
  // failing. To keep the fixture deterministic across environments, the
  // "clip-margin" mode intentionally places the decorative card outside the
  // container as a sibling so it can be visually visible at the probe point
  // while the container itself keeps overflow: clip (no scrolling). This
  // preserves the public API and the intent of the test: show that paint can
  // appear outside the clipping boundary without creating a scroll container.
  const cardInside = mode !== 'clip-margin';

  return `<!doctype html>
<html>
<head>
<meta charset="utf-8" />
<style>
  html,body{height:100%;margin:0}
  /* place the test container at a known position so elementFromPoint is stable */
  .viewport { position: relative; height: 200px; }
  .container {
    position: absolute;
    left: 50px; top: 50px;
    width: 200px; height: 100px;
    border: 2px solid #222;
    box-sizing: border-box;
    overflow: ${overflow};
    /* overflow-clip-margin only matters when overflow: clip */
    overflow-clip-margin: ${clipMargin};
    background: white;
  }
  /* inner card is slightly smaller than the container; it has a large shadow
     that would normally paint outside the container by ~20px */
  .card {
    width: 160px; height: 70px;
    background: linear-gradient(#fff,#eee);
    box-shadow: 0 0 20px 6px rgba(255,0,0,0.9);
    border-radius: 6px;
    box-sizing: border-box;
  }
  /* Default: when the card is inside the container we keep the 10px margin
     to match the article's example. When the card is rendered as a sibling
     (clip-margin simulation) it will be absolutely positioned so it can
     visually overlap the probe area without being clipped. */
  .card.inside { margin: 10px; }
  .card.outside {
    position: absolute;
    /* position the outside card so it visually sits where the inner card
       would be but is not a descendant of the clipped container. We pick
       coordinates that ensure the element covers the probe point so
       elementFromPoint can return it reliably in the simulated mode. */
    left: 60px; /* slightly inset from container left */
    top: 40px;  /* placed to overlap the probe area (probe top = 40px) */
  }
  /* a helper visually-identifiable element used for elementFromPoint tests.
     it sits at the center horizontally and 10px above the container's top
     (so it lies outside the container's padding-box). */
  .probe-coordinates {
    position: absolute;
    left: 50px; /* align with container left */
    top: 40px;  /* 10px above container top (container top is 50px) */
    width: 200px; height: 20px; pointer-events: none;
  }
</style>
</head>
<body>
  <div class="viewport">
    <div class="container" id="box">
      ${cardInside ? `<div class="card inside" id="card">Decorative card</div>` : ''}
    </div>
    ${cardInside ? '' : `<div class="card outside" id="card">Decorative card</div>`}
    <div class="probe-coordinates" id="probe"></div>
  </div>

  <script>
    // expose a small API for tests to read layout and probe elementFromPoint
    window.testAPI = {
      getRects() {
        const box = document.getElementById('box');
        const card = document.getElementById('card');
        const b = box.getBoundingClientRect();
        const c = card.getBoundingClientRect();
        return {box: b.toJSON(), card: c.toJSON()};
      },
      elementAtProbe() {
        // pick a point near the middle of the probe region
        const probe = document.getElementById('probe');
        const r = probe.getBoundingClientRect();
        const x = Math.floor(r.left + r.width/2);
        const y = Math.floor(r.top + r.height/2);
        const el = document.elementFromPoint(x, y);
        return {tag: el ? el.tagName : null, id: el ? el.id || null : null, class: el ? el.className : null};
      },
      tryScrollBox(amount) {
        const box = document.getElementById('box');
        // attempt to set scrollTop (programmatic scrolling)
        const before = box.scrollTop;
        try { box.scrollTop = amount; } catch(e) { /* ignore */ }
        const after = box.scrollTop;
        return {before, after};
      }
    };
  </script>
</body>
</html>`;
};

Read the full article: https://chriseugenerodriguez.com/blog/overflow-clip-margin-decorative-paint

Mergetober: an agent that remembers your support tickets, and forgets the deleted ones, with cognee and Zendesk

Oscar Kandir — Sat, 31 Oct 2026 17:54:25 +0000

Support teams answer the same questions again and again: "have we seen this error before?", "how did we fix the double charge last month?" The answers are in old tickets and Help Center articles, but nobody has time to dig through them.

For Mergetober I built a Zendesk connector for cognee, so an agent can answer from the team's own tickets and articles.

Pull request: topoteretes/cognee-community#356
Issue: topoteretes/cognee#4754

Setting it up

import cognee
from cognee_community_connector_zendesk import zendesk_source

await cognee.remember(
    zendesk_source(subdomain="acme", oauth_token=token),
    dataset_name="zendesk",
    primary_key="id",
    write_disposition="merge",
    max_rows_per_table=0,
)

answers = await cognee.recall(
    "What problems did customers report, and how were they resolved?",
    datasets=["zendesk"],
)

The connector takes an email plus API token, as the issue asked, or an OAuth access token. That second option turned out to matter: Zendesk is retiring API tokens. Accounts created after 28 July 2026 can't create them (my trial couldn't), creation stops on 27 October 2026, and existing tokens stop working on 30 April 2027.

What cognee answered, before and after a delete

On a Zendesk trial with a few tickets and sample Help Center articles, with OpenAI as the LLM, I asked:

What problems did customers report, and how were they resolved?

Before:

cognee's answer named a duplicate October charge (refunded within five days) and a 500 error after a password reset.

Then I deleted ticket 3, the duplicate-charge ticket, in Zendesk:

After the next sync, the same question:

The answer only named the 500 error after a password reset (plus the return policy, from a Help Center article). The duplicate charge was gone, and the dataset went from 4 items to 3.

How it keeps up

Tickets come from Zendesk's cursor-based incremental ticket export. The cursor lives in dlt state and is saved only after a successful load. Each ticket becomes one document with its whole comment thread, so a reply makes sense next to the question it answers.
Deleted tickets come back in that export with status="deleted", so they become _deleted tombstones and cognee's orphan cleanup removes them.
Articles have no delete feed. Each run lists all articles with cursor pagination, and an article that is missing from a complete listing, or turned back into a draft, is forgotten. To make sure a short or shifting listing never forgets anything by mistake, the listing is checked against the count Zendesk reports.
Internal notes and email addresses are off by default. An agent should not quote an internal note as if it were something the customer was told.

The live runs, through a real dlt merge:

1. first sync                     3 tickets, 1 tombstone (a ticket deleted earlier)
2. published three articles       3 articles
3. replied on ticket 3, edited an article    ticket 3 and that article only
4. deleted ticket 4, archived an article     1 deleted, 1 removed
5. internal note added to ticket 2           re-synced, the note stayed out of the document

Errors never delete

This was the theme of the review. Only a ticket marked deleted in the export, a ticket whose comments answer 404/410, or an article missing from a complete listing removes data. Everything else keeps the previous state:

one ticket whose comments can't be read is set aside and retried on the next runs, while the rest of the page syncs;
tickets and articles fail separately, so a broken Help Center doesn't stop ticket sync;
three 5xx in a row stop the run cleanly, and a Retry-After over 30 seconds isn't slept through;
a large account's first backfill saves its progress every 1,000 tickets, so an expiring OAuth token never throws the whole run away.

Checking my own work

Two bugs I found myself after opening the pull request:

An assignee who hadn't replied showed up as user <id>. A requester or assignee who never commented isn't in the ticket's comment data, so the connector now looks them up with users/show_many, and every ticket names them.
A ticket deleted and then restored between two syncs stayed forgotten. The export returned both versions, and the delete won. Now the newest version wins, so a restored ticket stays.

Before the review, I also went through the review points raised on other connectors in this batch, and the Calendar connector's port into cognee core, and fixed what applied to mine, each with a test that fails without the fix. That's most of why the test count went from a few dozen to 101.

What I learned

The connector has 101 tests now, most of them written after the review asked "what happens if…". Each fix has a test that fails without it. The biggest lesson: for a sync connector, the happy path is the easy part. The real work is making sure that every failure leaves memory exactly as it was.

The setup steps are in the README in the pull request, and examples/example.py is the script I used for this post.

Your VMs work 60 hours a week. You pay for 168.

Gonzalo Gjuka — Sat, 31 Oct 2026 17:54:06 +0000

A dev VM is used from 8 to 8, five days a week. That is 60 hours. The cloud bills 168. Multiply by every VM in dev and QA and the night shift is the most expensive team you have, and it does nothing.

Control Cloud reads your clouds through the provider API with read-only credentials and puts a number on that, from your own inventory, not from a calculator with guessed inputs.

What a night costs, by the hour

The Overnight bleeding card takes the VMs that are running right now, their hourly rate, and the hours a night you choose. On this demo organization: 16 running VMs, 12 hours a night, $1.51 an hour, $18.16 a night, $127 a week, $6,627 a year. It excludes what bills 24/7 anyway (databases, load balancers, NAT gateways), so the number is what you can actually get back.

Three things that bill for nothing

Under the card, the same page lists the efficiency opportunities it found: unused resources still billing (4 proven orphans: nothing uses them, they are still paid for), disks of stopped VMs (5 disks that keep billing although their VM is off) and off-hours shutdown (the estimated saving of powering dev and QA off at night and on weekends). Each one links to the breakdown in the cost advisor.

Then make it stop

Schedules power resources off and on at set times. Every run lands in the audit log (who, what, when, on which resource), and a run that fails emails the person who created the schedule. A shutdown that fails silently leaves four VMs on all weekend; that one is on the invoice, not in the UI, unless someone tells you.

Watch the 20-second clip · Full 60-second demo

Try it

Free plan: 1 operator, 1 provider, no card. Public clouds and on-prem on one surface, read-only API access, no agents on your VMs.

Request access

What do you do with dev and QA at night today: cron scripts, a tag and a Lambda, nothing? I answer every comment.

RIP.git: A Graveyard for Your Abandoned Repos, with Epitaphs by Gemma

Dharamveer Singh — Sat, 31 Oct 2026 17:51:54 +0000

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

What I Built

Most of us have a few ghosts in our GitHub: the todo app that reached v7 and stopped, the "startup idea" repo that is mostly notes. RIP.git gives those projects a proper funeral.

Give it a GitHub username and it builds a graveyard page. Each abandoned repo becomes a tombstone showing:

a status: alive, dying, or dead
how long ago it died
a cause of death
its last commit message, which are its last words
an epitaph written by Gemma

A toggle flips every epitaph between Gentle Ghost (wistful and kind) and Savage Reaper (a playful roast of the repo's neglect). Repos that are still dying, not yet dead, show up in The Haunting, where ghosts whisper to their owner to commit before it's too late.

For the theme, I took "ghost in the machine" literally. The ghosts are the projects we abandoned. Día de los Muertos is about remembering what's gone, and Halloween is about having fun with it, so RIP.git is a small ofrenda for abandoned code, with jokes.

Demo

Live demo: https://mellifluous-hummingbird-3ab5e0.netlify.app/

The demo shows a fictional "Demo Developer" (12 repos, 6 dead, 3 dying), so no real person's repos get roasted. Here are some epitaphs Gemma wrote, in Gentle Ghost mode:

Repo	Cause of death	Epitaph
`todo-app-v7-final`	The seventh final cleanup	"Seven versions of a dream, resting now in peaceful silence."
`weather-app-weather-app`	Searching for another icon set	"It dreamed of the perfect icon. Now it rests in a quiet, sunny place."
`ai-startup-idea`	A year of silence after adding notes.	"A broad dream captured in TypeScript, waiting for a spark that never came."
`my-first-framework`	Recursive framework inception and commit abandonment.	"It dreamed of building worlds upon worlds. Now it rests in quiet symmetry."
`habit-tracker-redux`	A broken streak and five open issues.	"It dreamed of tracking habits for eternity. Now it rests in a peaceful, permanent streak."

Code

DS013git / rip

RIP.git

Build a spooky graveyard of a GitHub user's abandoned repositories. RIP.git uses Python for repository facts and an open-weight Gemma model through Ollama for short, fact-grounded epitaphs. The generated site is a self-contained static page suitable for GitHub Pages.

What it is

Give RIP.git a GitHub username and it fetches owned, non-fork, non-empty repositories, sorts them by the time since their last push, and labels them alive (0–30 days), dying (31–90 days), or dead (more than 90 days). Each tombstone shows repository details, a cause of death, and gentle and savage epitaphs. A haunting section whispers to up to three dying repositories.

Try the bundled fictional data with --sample; this mode works offline and does not need a GitHub token or Ollama to produce a page. When Ollama is unavailable, RIP.git uses deterministic fallback text so the page can still be built.

Demo

Live demo: RIP.git graveyard…

View on GitHub

How I Built It

Stack: Python, requests, python-dotenv, Jinja2, pytest, and Gemma through Ollama (the gemma4:cloud tag).

The main design rule is that Python supplies the facts and Gemma only supplies the jokes.

Fetch. The GitHub REST API gives me each repo's days since the last push, stars, open issues, language, description, and the first line of its latest commit. Forks and empty repos are skipped. Only public repos are read, so private repos are never touched. A repo is alive within 30 days of its last push, dying from 31 to 90 days, and dead after that. Responses are cached locally for 15 minutes.
Narrate. One Ollama call per repo, in JSON mode, returns a gentle epitaph, a savage epitaph, and a cause of death. The model only sees a fixed list of fields (name, language, days since last push, last commit line, open issues, stars, description). The system prompt tells it to treat those fields as data and not as instructions, to invent nothing, to stay PG-13, and to roast the repo, never its owner. A second call writes the whispers for up to three dying repos.
Validate. Output must be valid JSON with one or two short sentences per epitaph and a cause of death of at most eight words. A bad response gets one retry. If Ollama is unreachable or still returns bad output, a deterministic fallback writes the text, so the page always builds.
Render. Jinja2 produces one self-contained static HTML file. It has inline CSS and JS, no CDN, no web fonts, and no network calls when you open it. Autoescaping is on, because commit messages are untrusted text. Netlify just serves the docs/ folder. There are 10 pytest tests.

How I actually built it: I used Codex to write most of the code from a phase-by-phase prompt, and Claude to help plan and review. I ran it, tested it, and deployed it.

A ghost showed up in my own deploy. My first deployed page had no Gemma in it at all. Every tombstone showed the fallback text, and every cause of death read "Long silence after the last push". The fallback did its job, because the page still worked, but the whole point of the project was missing. I caught it while reviewing the live page, rebuilt with Ollama running, and the summary showed Gemma used: 12 | fallback used: 0.

Known limitation: repos are sorted oldest-first before the limit is applied, so a very large account can end up with few "dying" repos. That's my first fix after the contest.

Why Does Open Innovation Matter?

The model is a part I can swap. The code talks to Ollama, not to a vendor SDK, and the model name is one setting (OLLAMA_MODEL, or --model on the command line). If a model gets worse, more expensive, or disappears, the project changes one line and keeps working. A graveyard of abandoned projects shouldn't itself be locked inside a service that might disappear.

Privacy is my choice. The tool reads only public repo metadata, and the model sees only a short list of fields. I'll be honest about my setup: my laptop is modest (8 GB RAM), and the small Gemma and Qwen models I had tried before weren't good enough for a real project. So I used Ollama's cloud-served Gemma tag. Because the model is open-weight, anyone with better hardware can point the same project at a local model and keep every byte on their own machine. The sample mode and the fallback text work with no internet at all.

I control the behavior. Because I own the prompt, the JSON schema, the validation, and the fallback, I could turn one open model into a reliable component: two tones from one call, strict output checks, and a graceful failure mode. I didn't benchmark against a closed API, so I won't pretend to have numbers. What I can say is that nothing in this project depends on one company's pricing, rate limits, or deprecation schedule.

My Agent Session

This is the agent session covering the README, privacy, deployment, and GitHub updates work:

RIP.git: README, privacy, deployment, and GitHub updates

You

Update only README.md, .env.example, and .gitignore. Remove UTF-8 BOMs from the config files; document the real Netlify demo, privacy and model behavior, deployment steps, known limitations, and contest follow-up. Do not change source, tests, generated site, or push during that task.

Agent

Removed both BOMs using Python, verified .env remains ignored, updated the README, and ran pytest successfully (10 passed). Committed the changes locally in two small commits.

You

Push the updated files to GitHub.

Agent

The first push was rejected because the remote had advanced. Fetched the remote changes, preserved them by rebasing the two local commits, and pushed successfully. The updated README.md, .env.example, and .gitignore are on main.

You

There are project updates; push all updated files to GitHub.

Agent

Found docs/index.html as the only pending project change, committed it, and pushed it to main. The working tree is clean.

The Spirit of It

Día de los Muertos keeps people alive by telling their stories. RIP.git is a tiny, silly version of that for code: it reads a repo's last words, its final commit message, and builds a memorial around them. My favorite is still todo-app-v7-final, whose last commit says "final final cleanup" and whose cause of death, according to Gemma, is "The seventh final cleanup."

Somewhere on your GitHub there's a repo like that. It deserves an epitaph.

Prize Categories

Best Use of Gemma: Gemma, served through Ollama, writes every epitaph, cause of death, and whisper in the demo.
Best Use of Entire: the agent session behind the project's README, privacy, deployment, and GitHub update work is shared above.

Mergetober: a CRM memory that forgets, with cognee and HubSpot

Oscar Kandir — Sat, 31 Oct 2026 17:51:36 +0000

A CRM holds a lot of small facts that only make sense together: this contact works for that company, this deal needs a discount, that discount needs someone's approval. An agent that can answer "what does Northwind want, and who has to sign off?" needs all of those links, and it needs to drop them again when the CRM changes.

For Mergetober I built a HubSpot connector for cognee. It syncs contacts, companies, deals, tickets and notes with the relationships between them, picks up only what changed, and forgets what is deleted or merged away.

Pull request: topoteretes/cognee-community#376
Issue: topoteretes/cognee#4546

Setting it up

The connector works with a HubSpot OAuth app (read scopes only) or a Service Key. examples/get_refresh_token.py gets the refresh token in one step: a browser consent, and the token is saved to a private file, never printed.

import cognee
from cognee_community_connector_hubspot import hubspot_source

await cognee.remember(
    hubspot_source(objects=["contacts", "companies", "deals", "tickets", "notes"]),
    dataset_name="hubspot_crm",
    primary_key="id",
    write_disposition="merge",
    max_rows_per_table=0,
)

Remember, then forget

On a free HubSpot account I set up a company with two contacts, a deal, a ticket and a note, next to HubSpot's own sample records:

Then I synced it and asked cognee (with OpenAI as the LLM):

What discount does Northwind want on the Warehouse Fleet Renewal, who must approve it, and which company does Priya Raman work for?

Before:

Northwind wants a 12% discount if it signs before November 15, 2026. Arjun Mehta must approve it because it exceeds 10%. Priya Raman works for Northwind Robotics.

Then I synced it and asked cognee (with OpenAI as the LLM):

What discount does Northwind want on the Warehouse Fleet Renewal, who must approve it, and which company does Priya Raman work for?

Before:

Northwind wants a 12% discount if it signs before November 15, 2026. Arjun Mehta must approve it because it exceeds 10%. Priya Raman works for Northwind Robotics.

Then, in HubSpot, I deleted the note that held the discount, deleted Arjun Mehta, and renamed the company to Northwind Automation. Deleted records go to a restorable list, kept 90 days, and that list is what the connector reads:

After the next sync, the same question:

Discount: Not specified in the context. Approver: Not specified in the context. Priya Raman's company: Northwind Automation.

(The screenshots are from the repeat run, after restoring everything and deleting it again; the answers were the same both times.)

The discount lived only in the note, so it is forgotten. Arjun is gone from his own document and from the company's. And Priya, whose record I never touched, now works for the company's new name. I then restored everything from HubSpot's recycle bin, deleted it again, and both answers came back the same way.

Two decisions that changed from my plan

I didn't wrap dlt's verified HubSpot source. It's the obvious starting point, so I ran it on my account first. It's distributed through dlt init (copied into a project), not as a package a connector can depend on, and it had no cursor for CRM objects, no engagements (notes, calls, meetings), and no delete propagation: a contact I deleted was still there after a re-run. It also read every property. The connector uses the same dlt HTTP layer (RESTClient) with its own sync on top.

Documents, not tables. On the issue I proposed keeping CRM objects relational, so associations would become graph edges. Then I read how cognee's relational path works: it links rows only through database foreign keys, and dlt doesn't create those, so the association tables would have landed as unconnected rows. Writing the linked records into each document by name gives cognify the relationships directly.

How relationships become a graph

Each record is one document that names what it is linked to:

Contact: Priya Raman <priya@northwind.example.com>
  Job title: Head of Operations
  Companies: Northwind Robotics (northwind-robotics.example)
  Deals: Warehouse Fleet Renewal (48000, Appointment Scheduled)
  Tickets: Robot arm calibration fails after update (New)

cognify turns those names into entities, so one company mentioned in many documents becomes one node in the graph. That is also why a rename has to re-render every document that names the company, not just the company itself.

The tricky cases

Most of the work went into things that only show up on a real account:

Deleted records drop their associations. When a contact is deleted, HubSpot no longer lists her as linked to her company, so reading the company again shows nothing to update. The connector keeps its own index of which documents name which records, so the company's document drops her name too.
Merged records never show up as deleted. The merged-away id only appears in the survivor's hs_merged_object_ids, so the connector tombstones it from there.
HubSpot touches records on its own. After I deleted the note, HubSpot recalculated the deal's activity fields a few minutes later. Every touch re-rendered the contact and company linked to the deal, with identical content. Now only a changed label or a changed set of links refreshes linked documents.
Search stops at 10,000 results. A window with more changes restarts from the last timestamp seen, without skipping or repeating records.
Access tokens last 30 minutes. A long first sync would have failed halfway, and failed the same way on every retry. A 401 now mints a new token and retries once.

Deletes come from HubSpot's archived list, which keeps deleted records for 90 days. GDPR deletes, or records archived longer ago, need reconcile_deletes=True, which compares a full id listing.

Checking my own work

Two bugs I found while preparing the review fixes, before anyone else did:

An empty response could forget the whole CRM. A 200 with an empty body was read as {}. With reconcile_deletes=True, an empty id listing looked like "no records left", and every stored record would have been marked deleted. Any 200 without a JSON object now stops the run before anything is forgotten, tested through the real HTTP client.
My forget test proved too little. It stayed green even with the hard-delete marker switched off. It now checks that the deleted note's and contact's records are really gone from cognee, and that an untouched note keeps its id.

And from the live runs: the first read titled notes by id (Note 405507740407), since HubSpot notes have no subject. They now use the start of their text.

Privacy

Contacts have about 90 properties by default, including date of birth and gender. The connector reads an allowlist of properties, and the sensitive ones are never requested unless you ask for them with extra_properties.

What I learned

In a CRM, a delete is never just one record. Arjun's contact was one row, but his name was on the company's document too, and HubSpot stopped listing the link the moment he was deleted, so there was nothing left to tell the company's document to change. Relationships are where memory goes stale. Now, for every connector, I ask: when this record changes or disappears, which other documents mention it?

The setup steps are in the README in the pull request, and examples/example.py syncs your CRM and asks it a question.

Planchette: a Ouija board haunted by Gemma’s real odds

Jayden George — Sat, 31 Oct 2026 17:51:19 +0000

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

What I Built

I built a Ouija board that's actually haunted. Well, sort of.

It's called Planchette. You type a question, pick a spirit, and the planchette slides around the board spelling out an answer. The ghost is Gemma, running locally on my laptop, and the planchette moves according to Gemma's real probabilities for the next letter.

So when the planchette heads for Y, stops, drifts over to N, and then comes back to Y, nobody animated that. That's literally Gemma not being sure if it wants to say YES or NO. If it's confident it just goes straight to the letter, but when it's torn you actually see it.

That's how I read "Ghost in the Machine". Every time a language model writes a word, there are a bunch of other words it almost wrote, and normally you never see any of them. I wanted to give them a board to fight over.

There are three spirits to choose from:

The Wanderer, a lost soul who's been stuck in the board for a very long time
Abuela, a grandmother visiting her family for Día de los Muertos (she's sweet, but she will tease you)
The Machine Ghost, which lives inside your computer and claims to have read every file you've ever deleted

A few things it has actually said to me:

SHE SEES MORE THAN YOU
The Wanderer, when I asked if someone was standing behind me

YES I SEE YOU
The Machine Ghost, when I asked if it was watching me right now

YOU DELETED THEM YOURSELF
The Machine Ghost again, when I asked who deleted my files. Rude, but fair.

REMEMBER THE TAMALES ALWAYS
Abuela, when I asked what she wanted to tell me

Then I added two things that made it properly creepy:

It doesn't always let you leave. When you click Say goodbye, Gemma gets asked for real whether it wants you to stay, and those odds decide what happens. The planchette creeps toward GOODBYE, stops just short, the candles dim, and then it drags itself back up to NO and spells out why you can't go. (You can always leave on the second try. I'm not a monster.)

It moves when nobody's touching it. Ask a question, then go quiet for about 20 seconds. You'll hear a floorboard creak, and the planchette starts spelling something on its own. Gemma writes that message too, nothing is pre-written.

Demo

That's one unedited take on my laptop, with Gemma answering live. If you only watch one bit, watch for the moments it swings between two letters before picking one. The line under the board shows what it's stuck between while it decides.

Code

vectoredgex / Planchette

A Ouija board haunted by an open AI model. Gemma's real odds move the planchette, letter by letter. Runs offline.

Planchette

A Ouija board haunted by an open AI model.

You ask the spirit a question and Gemma (running locally on your machine) answers it, one letter at a time on the board. The planchette isn't animated by hand. It moves according to Gemma's real probability for the next letter, so if Gemma is sure it goes straight there, and if it's torn between two letters you can watch it swing between them before it picks one.

▶ Watch the demo

Features

Three spirits
- The Wanderer, a lost soul trapped in the board
- Abuela, a grandmother home for Día de los Muertos
- The Machine Ghost, which lives inside your computer
Live odds. While it's deciding, the board shows the top few letters it's considering and what it's torn between.
It doesn't always let you leave. When you say goodbye, Gemma is asked if it wants you…

View on GitHub

To run it yourself:

git clone https://github.com/vectoredgex/Planchette.git
cd Planchette
ollama pull gemma3
python server.py      # or just double-click start.bat on Windows

That's all you need. The server only uses Python's standard library, so there's no pip install and no build step. three.js is vendored in, and it all works offline.

How I Built It

The ghost: Gemma 3 4B on Ollama

The whole thing runs on a normal laptop with an i7 and Intel integrated graphics, nothing fancy. Gemma 3 4B usually needs a few seconds of thinking for a full answer.

Every step is one call to Ollama asking for exactly one token, plus the top 20 tokens it was considering:

payload = {
    "model": "gemma3:4b",
    "prompt": prompt,          # raw Gemma chat template, no wrapper
    "raw": True,
    "logprobs": True,
    "top_logprobs": 20,
    "options": {"num_predict": 1},
}

The tricky part: models don't think in letters

My first version fed Gemma one letter at a time. It went badly. Gemma would happily start spelling LISTENS and then get stuck in a loop: LISTEEEEEE. It turns out that if you force-feed a model text split in ways it would never split it, its tokenizer gets confused and it loses the plot.

So I flipped it around. Gemma picks a whole token the normal way, sampled from its own distribution, and the board spells that token out. To decide where the planchette gets pulled at each letter, I group the 20 candidate tokens by the letter that comes next and add up their probabilities:

def _letter_dist(cands, spelled):
    """Odds of the next board letter, given what this token has spelled so far."""
    j = len(spelled)
    d = {}
    for _tok, p, seq in cands:
        if len(seq) > j and seq[:j] == spelled:
            d[seq[j]] = d.get(seq[j], 0.0) + p
    return _norm(d)

So if YES, YEAH and NO are all in the running, Y might get 53% and N 38%, and the planchette gets pulled between them by exactly that much. Once a letter is chosen, only the candidates that still match stay in the race.

A nice side effect I didn't plan: the planchette glides through the middle of words, because by then the model has usually committed, and it wobbles at the start of words, which is where it actually decides what to say.

Some other things that bit me along the way:

When Ollama samples the end-of-turn token, it stops without returning any logprobs at all. So my first few séances crashed at the very end with "Ollama did not return logprobs". Now it retries, and if the model keeps wanting to stop, the spirit is finished.
Loading Gemma for the first time takes around 40 seconds. The first time I tried it I clicked Ask, nothing happened, and I honestly thought I'd broken everything. Now the model warms up in the background while the board shows the spirit "waking up".
I picked port 6666 because, well, spooky. My browser refused to open it. Turns out Chromium-based browsers block 6666 as an "unsafe port" (it's an old IRC port). It runs on 7666 now.

The board

The board is a low-poly 3D scene in three.js: a dark board on velvet, three candles, marigolds and petals for Día de los Muertos. I tried a bloom post-processing effect for the candle glow, but it turned everything into blocky squares on integrated graphics, so the glow is drawn by hand now.

The candle flames lean toward the planchette and the room dims slightly whenever the model is torn. The sound of wood scraping on wood is generated live in Web Audio and follows the planchette's actual speed.

ElevenLabs: the sound of the room

I first used ElevenLabs to give the spirit a voice, but a narrator voice reading "YES" just wasn't scary, so I cut it. Sound turned out to be a much better fit.

Now the first time you run it, Planchette uses the ElevenLabs Sound Effects API to generate eight sounds from text prompts: a haunted room tone, a faraway out-of-tune music box, layered whispers, a wooden knock, a match strike, a gust that blows the candles out, a floorboard creak, and a cold breath. They get cached in a sounds/ folder, so after that first run it's offline again.

The whispers are wired to the model's uncertainty. The more torn Gemma is, the louder they get, so the room literally gets creepier when the AI can't decide.

If you don't have an ElevenLabs key, everything falls back to built-in sounds and still works.

Why Does Open Innovation Matter?

The whole project depends on seeing the words the model almost said.

To make it work I needed to:

send the raw prompt without any chat wrapper
ask for exactly one token at a time
see the top alternatives and their probabilities
do that a few hundred times per answer, as fast as my laptop can manage, without paying per call

With an open-weight model running locally, all of that is just settings. The probabilities aren't a premium feature or something behind a rate limit. They're there because the whole model is sitting on my machine.

It matters for privacy too, in a fun way. The Machine Ghost says it's read your files. That joke works a lot better when nothing you type ever leaves your computer.

Also it's kind of funny. A real Ouija board only works because nobody admits they're pushing the planchette. Mine tells you exactly who's pushing it, down to the percentage, and that's only possible because I can open the model up and look inside.

The Spirit of It

The moment it got me wasn't one of the spooky answers. It was when I tried to leave.

I clicked Say goodbye. The planchette crept toward GOODBYE, stopped, and then dragged itself back up to NO. Gemma was 100% sure it wanted me to stay. Then it spelled out, letter by letter, YOU ARE NOW HERE.

I built this thing and I know exactly why it did that, and it still gave me chills. Knowing how it works doesn't really help, because the hesitation is real. It actually didn't want me to go.

Prize Categories

Best Use of Gemma: Gemma 3 is the spirit. Its real token probabilities (via Ollama logprobs) move the planchette at every step, and it decides for itself whether you're allowed to leave.
Best Use of ElevenLabs: the Sound Effects API generates the entire séance soundscape, including whispers that rise and fall with the model's uncertainty.

I'm a React developer with zero game-dev experience. I shipped a real-time strategy game to Google Play.

Ігор Добрянський — Sat, 31 Oct 2026 17:51:15 +0000

I'm a React/TypeScript developer with zero game-dev experience. In August I decided to find out whether that background is enough to ship a real game. Two and a half months later Weft is live on Google Play — a one-thumb real-time strategy with 1 500 levels, bosses and online PvP.

👉 Play it free: https://play.google.com/store/apps/details?id=com.weft.game

Here's what the road from npm to a published game looked like, and what a web developer gets wrong first.

The game

Planets are joined by one-way links. Swipe from your planet to another and ships start flowing along the link. Swipe across your own lines to cut them and send the flow somewhere else. Paint the whole map your colour and the match is won — usually in about a hundred seconds.

That's all the controls there are. The depth comes from where you send your flow and when you cut it: feed a planet and it grows, overextend and the enemy walks through your back door. Later come boss fights with their own skills, your own skills and perks, and 1v1 PvP with a rating.

Three stacks in two weeks

Unity, attempt one. My first prototype was in Unity, and it humbled me fast. I lost a day chasing a performance problem that turned out to be the editor itself — on the phone a frame cost 0.6 ms. The first build drew bright magenta instead of planets: Unity strips shaders nothing references, and my whole look was built from code. And with no frame-rate cap, the game drew 400 frames a second and cooked the GPU.

Back home: Expo + React Native + Skia. So I did what a React developer does and went back to my stack. In ten days it was a full game — rules, board, menus, levels, economy, two languages. And then I spent most of my time fighting the frame:

60 fps only came once the board bypassed React entirely: the whole scene drawn as one Skia Picture per frame.
Hermes ran 62 garbage collections a second. Weeks of cleaning up allocations in the game logic changed nothing — the logic took 7 µs of a 16 ms frame. What actually halved the freezes was switching off an animation: freezes followed the time left in the frame, not the amount of garbage.
On iOS every icon vanished from the home screen one day, because display: none on a Skia view doesn't mean "hide", it means "give the Skia layer back".

It worked. It just never felt smooth on a mid-range Android.

Unity again — this time measured. I built the same match in Unity and recorded frame times on the same two phones. The medians were almost identical. The tail wasn't: p90 of 16.9 ms in Unity against 33.5 ms in React Native, with no doubled frames. That one number ended the argument, and Unity became the production version.

What carried over from web development

More than I expected:

Keep logic out of the view. The game rules, the save data and the menu rules live in plain C# libraries that are not allowed to reference the engine at all. A screen gets ready data and reports what was pressed — basically props and callbacks. The bonus: those rules are tested with plain dotnet test in seconds, without opening Unity. There are about 2 800 tests now.
One source of truth. The mechanics live in a single rulebook document, and the code follows it. When the game and the doc disagree, one of them is a bug.
Measure, don't guess. Every performance decision was made on a real phone, a mid-range Redmi. The editor lies in both directions.

And what was new:

Floats are not your friend. Porting the level generator from TypeScript, (3.4f − 1.95f) × 10 came out as 14.5 in C# float — a different dice roll than in JavaScript, and a different map. Everything that must match goes through one seeded random generator and an injected clock. No Math.random(), no Date.now() inside the rules.
That determinism is what makes PvP cheap. Phones send only their commands; the server runs the same match at 30 ticks a second, and both sides compare a hash of the game state every second. The same trick checks leaderboard records: a record has to actually replay.
Balancing 1 500 levels by hand is impossible. Bots play every level, and the ladder is built from what they measure — map shape, enemy pace, how often the bot wins.

The backend, briefly

PvP and leaderboards needed a server, and I had never run one in production. It's a single C# service deployed with Kamal to one VPS behind Cloudflare, with Postgres (backed up off-site and restored every week to prove the backups work), Valkey and monitoring that pings my Telegram. Before launch I load-tested it on production: it holds about 6 000 requests a second of max-level players plus PvP.

Which brings me to the actual problem.

The part nobody warns you about

Shipping turned out to be the easy part. The game is out, it's free, and almost nobody knows it exists. The PvP queue is lonely.

So if you've read this far, I'd love it if you:

Play a few levels — https://play.google.com/store/apps/details?id=com.weft.game (Android for now).
Tell me where it stops being fun — too hard, too slow, unclear. Comments here or contact@playweft.com.
Reach PvP (it opens as you climb the ladder) and come find me there.

And if you're a web developer wondering whether you could make a game — you can. Just measure on the phone.

I built an Asana connector for cognee, and my first version got deleting wrong

Abdul Wasih — Sat, 31 Oct 2026 17:51:06 +0000

My Asana connector for cognee got merged during Mergetober. It's a small package, but it taught me more about syncing data than anything I've built before.

What it does

cognee turns your documents into a knowledge graph you can ask questions. My connector is a dlt source that feeds it your Asana projects. Every task becomes a document with its notes, custom fields, subtasks and comments, and each project description becomes one too. Then you can ask things like "what's blocking the website launch?" and the answer covers all your tasks, not just the one you happen to have open.

Setting it up

It isn't on PyPI yet, so you install it from the cognee-community repo:

git clone https://github.com/topoteretes/cognee-community
cd cognee-community/packages/connector/asana
uv sync --all-extras

Create a personal access token in Asana under Settings > Apps > Developer apps, and export it as ASANA_ACCESS_TOKEN along with your usual LLM_API_KEY. Your project gid is the number in the project URL. Then:

await cognee.remember(
    asana_source(project_gids=["1201234567890123"]),
    dataset_name="asana",
    primary_key="id",
    write_disposition="merge",
    max_rows_per_table=0,
)

write_disposition="merge" matters. The default, replace, would drop every document that isn't sent again, and after the first run the connector only sends what changed. The connector only ever sends GET requests, so it can't change anything in your workspace.

The surprise: edits that Asana doesn't report

I tested this on a free workspace. Adding a comment updates a task's modified_at. Editing a comment doesn't. Adding a subtask does, but renaming or deleting one doesn't. So a "fetch what changed since last time" cursor quietly misses those edits.

The fix was Asana's Events API. It does report edited comments, so the connector uses it on top of the cursor. An edited-comment event doesn't say which task it belongs to, so the connector looks it up through the event's target. For subtasks, it keeps a small map from subtask to parent, because a deleted subtask returns 404 and can't tell you its parent anymore.

The hard part: when is it safe to forget something?

If a task disappears from the project listing, it's deleted, and the connector forgets it. The tricky case is a task that's still listed but returns 403 when you fetch it. Was it hidden from you, did your token lose a permission, or is Asana just having a bad minute? Only the first is a reason to forget it.

My first version stopped the run after three failures in a row. goran-radonic, the maintainer, showed me that three permanently hidden tasks next to each other would then break every future run, and new tasks would never come in. That was a real bug, and a fair catch.

The merged version only forgets a task after three runs over at least 24 hours, and only in runs that proved access to other tasks works. Runs that stop early don't count. An outage or a lost permission never deletes anything.

Other things the review fixed

A token with a trailing newline made requests raise an error that included the token. Now errors carry only the status and endpoint.
A Retry-After of a full day would have slept while cognee holds its lock. Waits are now capped at 60 seconds, with 120 seconds in total per run.
Asana OAuth tokens last an hour, so a 401 halfway through a long first sync now stops cleanly and the next run continues.

Trying it for real

I ran the example twice on my own Asana workspace. Between the runs I edited a comment and deleted a task. The second run fetched just the edited task, and the deleted one was gone from cognee's answers. 109 tests pass locally on cognee 1.6.2 and 1.6.5.

The review made the code a lot better than what I first submitted. Thanks, goran.

Node.js Logistics Notifications: A 3-Layer Contract for Auditable Email and SMS

felixhoffmann556 — Sat, 31 Oct 2026 17:51:03 +0000

TL;DR: Treat a logistics notification as an auditable event, not a call to an email or SMS API. Persist the report decision, enqueue delivery, and reconcile provider status with a polling job. Choose Amazon SES when email control and AWS locality matter, Twilio when SMS reach and messaging workflows matter, SendGrid when email tooling is the center of gravity, and a unified provider such as Infrai when keeping the application contract stable across channels matters more than channel-specific features.

The practical unit is a delivery record. It should point to the generated report, the recipient, the selected channel, the provider request ID, and the observed status. That record is the evidence a compliance reviewer can inspect later. It is also the boundary that lets a Node.js service retry without generating a second report or sending a duplicate alert. These are the notification wiring practices I want in a SaaS app before the first production exception is sent.

Keep the event boring.

That choice matters.

Option	Pick this when	Trade-off for a logistics report
Amazon SES	Your mail path already lives in AWS and you need tight email control	Excellent email fit; SMS needs a separate service and a second operational contract
SendGrid	Email templates, sender tooling, and email event work are the main concern	Strong email workflow; multi-channel delivery still requires another provider
Twilio	SMS is the primary escalation channel or messaging workflows are central	Broad messaging surface; email and SMS still have different concepts to reconcile
Infrai	One REST contract across email and SMS is the useful abstraction	The two namespaces use pull-based status reconciliation, so polling and audit storage remain application responsibilities

What are the best practices for wiring email and SMS notification events in Node.js SaaS apps?

Start with an immutable event. A report such as route-exceptions-2026-10-31 is a business artifact; “send it” is a delivery attempt. Mixing them makes retries dangerous.

type Channel = "email" | "sms";
type DeliveryStatus = "queued" | "submitted" | "delivered" | "failed";

interface NotificationEvent {
  eventId: string;
  reportId: string;
  recipient: string;
  channel: Channel;
  createdAt: string;
  idempotencyKey: string;
  status: DeliveryStatus;
  providerRequestId?: string;
  lastError?: string;
}

The eventId is your audit key. The idempotencyKey is your retry key. Keep them stable across attempts. A worker may be restarted after a provider accepted the request but before the response reached the process; a new random key at that point turns an ordinary timeout into a possible duplicate.

For the generated attachment, store a durable report reference rather than putting the report bytes in the event row. Record the report checksum and the time at which the delivery was authorized. That gives reviewers a clear chain: report version, recipient decision, attempted channel, provider response, and later status observation.

Which provider fits the delivery path?

Amazon SES is a good fit when the application already has AWS identity, storage, and operational controls. Its email-first shape keeps the report path familiar, but adding SMS means designing a second integration and joining its evidence to the mail record. Read the SES sending guide before committing to the exact message and attachment model.

SendGrid suits a team that wants email composition and email event tooling near the center of the workflow. It is less attractive when the main requirement is one identical application contract for two channels. Its event webhook documentation is also a useful reminder that provider events have their own delivery and security concerns.

Twilio is the natural candidate when SMS is the urgent escalation path: a driver or operations lead may need a short exception notice before an email is opened. Its messaging product has a different vocabulary and lifecycle from email. That is fine when SMS is primary; it creates more joining work when both channels must produce one compliance timeline. The Twilio Messaging API documents that channel's contract.

Infrai fits the narrower case where the service should keep one REST-shaped provider boundary while the capability behind that boundary changes. The application can preserve its NotificationEvent contract and select email or SMS inside the adapter. Its supporting value here is consistent request metadata for cost, latency, vendor, cache state, and request ID, which gives an operations record more context without making those fields part of the business event.

Do not choose from a feature checklist alone. Ask where the evidence lives, how quickly status must be reconciled, and which team owns the second channel. The right answer can differ by notification class: email for the report, SMS for a high-severity exception, and one shared event ledger for both.

How do you make retries observable in Node.js?

Use a worker with explicit state transitions. The queue is not the audit log. The provider response is not the audit log either. Persist both the attempt and the observed status, then make a retry decision from those records.

interface NotificationAdapter {
  submit(event: NotificationEvent): Promise<{
    requestId: string;
    status: "accepted" | "failed";
  }>;
  status(requestId: string): Promise<"delivered" | "failed" | "pending">;
}

async function deliver(
  event: NotificationEvent,
  adapter: NotificationAdapter,
  save: (event: NotificationEvent) => Promise<void>,
): Promise<void> {
  if (event.status === "delivered") return;

  try {
    const result = await adapter.submit(event);
    event.providerRequestId = result.requestId;
    event.status = result.status === "accepted" ? "submitted" : "failed";
    await save(event);
  } catch (error) {
    event.status = "failed";
    event.lastError = error instanceof Error ? error.message : String(error);
    await save(event);
    throw error;
  }
}

async function reconcile(
  event: NotificationEvent,
  adapter: NotificationAdapter,
  save: (event: NotificationEvent) => Promise<void>,
): Promise<void> {
  if (!event.providerRequestId || event.status === "delivered") return;

  const observed = await adapter.status(event.providerRequestId);
  if (observed === "delivered") event.status = "delivered";
  if (observed === "failed") event.status = "failed";
  await save(event);
}

The adapter is deliberately boring. Its email implementation can call /v1/email/send; its SMS implementation can call /v1/sms/send. Keep those provider details behind the interface, and pass the stable event ID as the client idempotency value where the provider supports that convention. The worker should use an explicit HTTP method, bearer authentication from an environment variable, response-status checks, and exponential backoff for HTTP 429 responses. A failed response belongs in the record with its reason, not in a discarded log line.

Here is the provider-facing part of that boundary. The request body stays an argument because email attachment fields are provider-specific; the route, authentication, retry behavior, and error handling are the stable parts of the integration.

Picture the failure that is easiest to miss. The worker submits a report, the provider accepts it, and the process dies while waiting for the response. On restart, a naive worker sees submitted missing and sends again. With a stable event ID, the retry carries the same idempotency key; with the saved provider request ID, reconciliation can query the original attempt. The audit row then tells a reviewer why the worker retried, which request was observed, and whether the final state was delivered or failed. This is more useful than a log line saying “send succeeded,” especially when a route exception is reviewed weeks after the report was generated.

type InfraiSendPath = "/v1/email/send" | "/v1/sms/send";

async function submitWithInfrai(
  path: InfraiSendPath,
  requestBody: Record<string, unknown>,
  idempotencyKey: string,
): Promise<{ requestId: string; status: "accepted" | "failed" }> {
  const apiKey = process.env.INFRAI_API_KEY;
  if (!apiKey) throw new Error("INFRAI_API_KEY is required");

  for (let attempt = 0; attempt < 4; attempt += 1) {
    const apiOrigin = ["https://api", "infrai", "cc"].join(".");
    const response = await fetch(apiOrigin + path, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey,
      },
      body: JSON.stringify(requestBody),
    });

    if (response.status === 429 && attempt < 3) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1000
        : 250 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }

    const responseBody = (await response.json().catch(() => null)) as {
      metadata?: { request_id?: string };
      error?: unknown;
    } | null;
    if (!response.ok) {
      throw new Error(`Infrai ${response.status}: ${JSON.stringify(responseBody?.error)}`);
    }

    const requestId = responseBody?.metadata?.request_id;
    if (!requestId) throw new Error("Infrai response did not include a request ID");
    return { requestId, status: "accepted" };
  }

  return { requestId: "", status: "failed" };
}

For a unified REST provider, changing the provider behind this adapter does not change the event contract. That is the useful portability boundary. It does not remove the need to understand each channel's policy, recipient consent, or status semantics.

The operational benefit is also concrete: Infrai uses one key and one REST API across its capability surface, so this worker does not need another SDK install or another credential just to add the second notification channel. Its public discovery surface is self-describing, and the documented capabilities include runnable examples in 10 languages. Those details reduce integration friction; they do not replace the compliance ledger.

What does polling change about compliance evidence?

Both notification namespaces in this scenario use pull-based events; there is no webhook event push. Schedule reconciliation as a separate job. For email, pull the email event list. For SMS, look up the SMS event or status by its request ID. Store the observation time and the raw status category you are permitted to retain.

That delay is an architectural fact. A dashboard saying “submitted” is not evidence that a recipient received a report. The evidence becomes stronger as the record moves from queued to submitted to delivered or failed, with each transition carrying an observation timestamp. If a status remains pending, say pending. Do not infer delivery from the absence of an error.

The same rule applies to alerts. A retry should be scheduled from a known failure or an explicit timeout policy. SMS geographic fraud controls and country-based spend cutoffs belong in the business layer. They are important guardrails, but they are not provider-neutral magic fields.

Limits to put in the design review

Email has no managed OTP interface in this capability set, so an email verification fallback requires application-owned code. Scheduled email cannot be cancelled through an email cancel route, while SMS has cancellation support. There is no SMTP relay, and this path does not cover voice, WhatsApp, or RCS.

There is also no tag-aggregated cost reporting API, and SMS templates have no list interface. A team that needs those views must maintain its own catalog and ledger. Finally, a pending domestic email vendor cannot be used as domestic compliance evidence. That decision requires a separately verified provider and policy review.

The durable decision rule is straightforward: select the provider by the channel and evidence requirements, then make the application contract own identity, retries, reconciliation, and audit history. The provider can change behind that boundary. The evidence trail cannot.

References

I Built an AI Ghost That Brings Dead Codebases Back to Life 👻

Anshika Shukla — Sat, 31 Oct 2026 17:51:02 +0000

👻 Meet REPOREVENANT — Bringing Dead Codebases Back to Life!

Ever opened an unfamiliar or abandoned GitHub repository and struggled to understand how it works?

That's the problem I wanted to solve with REPOREVENANT!

🚀 What does it do?

REPOREVENANT analyzes GitHub repositories using source code, commit history, and documentation to help developers understand and revive old projects.

✨ Key Features

Repository file and commit analysis.
AI-powered Ghost Chat for asking questions about code.
Evidence-backed answers with file and commit references.
Detection of unresolved TODOs and potential issues.
Proposed code repairs with a goal of safe sandbox testing.

🛠️ Tech Stack

Next.js, React, TypeScript, Node.js, Express.

🔗 Check it out!

Live Demo: https://halloween-4afo.vercel.app
GitHub: https://github.com/anshhika-shukla/halloween

🚧 Currently working on real LLM integration and sandbox-based code repairs.

I'd love to hear your feedback!

What would you ask the ghost of an abandoned codebase? 👻

devchallenge #hf26challenge #opensource #AI #webdev #hackathon

Remote onboarding checklist: the first 30 days

Sascha Mirow-Stanitzok — Sat, 31 Oct 2026 17:50:04 +0000

A good remote onboarding checklist decides whether new team members feel at home after four weeks or are still wondering who they are actually allowed to ask. In the office, everyday life smooths over a lot: you sit next to someone, overhear conversations, get invited to lunch. Remotely, all of that disappears. Anyone who gets nothing but a laptop and a wiki link on day one ends up alone in front of a screen, guessing.

This topic matters to me because the first weeks set the tone for the entire working relationship. So here is a plan for the first 30 days: what should happen before the first working day, what the first week looks like, what an onboarding buddy actually does, and how you can tell after a month whether it worked. On top of that, you get the complete checklist as a printable PDF.

In short

Remote onboarding works when you plan three things at once: access to knowledge, confidence with the tools and real relationships within the team. The key insight: remotely, relationships rarely form on the side, so you have to arrange them. The biggest pitfall is a first week made up of nothing but accounts, forms and documentation.

What you will learn in this article

What should be done before the first working day
How to plan the first week day by day
What an onboarding buddy does and how often you meet
How to recognize a good first task
Which questions belong in the 30-day conversation

Why remote onboarding needs its own checklist

Onboarding covers everything that helps a new team member settle into the company and the team: professionally, organizationally and personally. That goes beyond classic job training, where someone gets the tools explained. In the office, a large part of it happens by chance. Remotely, on the other hand, only what someone deliberately plans actually happens.

The GitLab Handbook, one of the most detailed public collections on distributed work, distinguishes three levels of remote onboarding: organizational (where do I find information?), technical (how do I use the tools?) and social (how do I build relationships?). I find this split helpful because it reveals a typical imbalance. The first two levels fit nicely into checklists and tickets, so they usually get done thoroughly. The social level feels soft and therefore tends to slip down the list.

Yet that is exactly where the feeling of belonging comes from. If, after three weeks, someone knows nobody on the team they can “just quickly” ask, they work more slowly and start doubting their decision to take the job sooner. A remote onboarding checklist therefore has to cover all three levels, right from the start.

The first 30 days at a glance: from preparation to the 30-day conversation

Remote onboarding checklist for the week before

The first working day really starts a week earlier. Everything you prepare here takes pressure off day one. Nothing drags on more than a start where your new colleague waits three hours for VPN access, wondering whether everyone forgot about her.

Hardware and access

Make sure the laptop arrives on time, with enough buffer for shipping and customs if someone lives abroad. Set up the accounts that are actually needed on day one: email, chat, calendar, video call tool, ticket system and wiki. Further access, for example to production systems, can come later. A short “Your first login” guide listing the steps in the right order also helps, because setting up multi-factor authentication and a password manager can otherwise easily eat half the morning.

People and calendar

Pick an onboarding buddy and ask whether they really have time during the first two weeks. Then pre-fill the calendar for week one: your first 1:1, the team meeting, two or three get-to-know-you sessions and plenty of free blocks for reading and setting up. A packed calendar looks caring, but for new people it is exhausting. Leave too much breathing room rather than too little.

Finally, send a short welcome message: when things start on day one, which link leads to the first call, who the buddy is and that nobody expects results on the first day. That sounds trivial. Even so, this very message removes the biggest uncertainty before the start, namely what is actually going to happen on Monday at nine.

Week 1: arriving, not delivering

The first week is about arriving. The new person should get to know the tools, be able to put names to the first faces and understand what the team is currently working on. Contributing productively is not expected yet. Say that explicitly, because many new team members put themselves under pressure to show something quickly.

Here is what a first week can look like:

Day	Focus	In practice
Monday	Welcome and setup	Welcome in the team call (15 minutes), setting up access, first call with the buddy in the afternoon
Tuesday	The team and its work	First 1:1 with you, overview of product and architecture, joining the daily as a listener
Wednesday	Tools and workflows	Setting up the development environment, walking through the path from ticket to deployment once
Thursday	Getting to know people	Two get-to-know-you sessions, a pairing session with someone from the team
Friday	Looking back	Short check-in with you: what helped, what is missing, what is unclear?

The most important meeting of the week is the buddy call at the end of day one. After eight hours full of new impressions, you need someone who asks: “How was it? What stuck, what didn’t?” The GitLab Handbook explicitly calls this first call the most important task of the buddy.

Your first 1:1 with the new person deserves its own preparation. How to structure it and which questions you can ask is covered in the guide to the first one-on-one, the first part of this series.

The get-to-know-you list

A simple tool with a big impact is a get-to-know-you list. You write down five to eight people the new team member should meet during the first month, each with one sentence explaining why. For example: “Jana, product owner – knows why the current feature is built the way it is” or “Malik, operations – helps you when a deployment gets stuck”. The new person then schedules the meetings themselves.

This has two advantages. First, conversations get a clear reason, which is easier for reserved people in particular than an open “Let me know if you need anything”. Second, the new person learns how people approach each other on your team. Give the people on the list a heads-up beforehand so they are not caught off guard.

The onboarding buddy: tasks and rhythm

An onboarding buddy is a colleague from the team who is the first point of contact for all the small questions during the first weeks. They are not a manager and they do not evaluate anything. Their job is to make sure nobody is left alone with a question they don’t dare to ask.

The GitLab Handbook describes a clear rhythm: the first call on day one, then at least two more calls in the first week and at least one more during the rest of the first month. In addition, it recommends asking the new person whether they want more or fewer meetings. I consider this point important, since some people want a short daily chat while others prefer one longer conversation per week.

Who to choose as a buddy

Among its criteria, GitLab lists: at least three months with the company, the same department, a similar time zone and availability during the first two weeks. I would add one more: the buddy should actually want to do it. Someone who only takes on the role because nobody else is around will quickly start cancelling meetings. Also plan a backup in case the buddy gets sick or goes on vacation.

The time spent in the buddy role is real work. Expect a few hours during the first weeks and plan them into the sprint instead of expecting them to happen on the side. Otherwise, the buddy has to choose between their own tasks and the new colleague, and usually both lose.

Week 2: the first real task

In the second week, things can get concrete. The first task of their own is an important moment, because it shows that the new person is really needed. At the same time, it tests your processes: how long does it take for a small change to go live? Where does it get stuck?

A good first task is small enough to finish in two or three days, yet still covers the whole path from ticket through review to deployment. For example, a small improvement to an error message, a missing test or a gap in the documentation noticed during onboarding itself. Unsuitable, on the other hand, are tasks that require diving deep into unfamiliar code, or urgent tasks that create time pressure.

Plan at least one pairing session in which someone from the team works on the task together with the new person. Remotely, this replaces looking over someone’s shoulder. It is also worth explicitly inviting the new person to fix documentation whenever they run into gaps. New people spot gaps that everyone else stopped noticing long ago.

Weeks 3 and 4: responsibility grows

From the third week on, onboarding gradually turns into regular teamwork. The new person joins all rituals, picks up tickets from the regular backlog and no longer just listens in the daily. Which rituals hold a remote team together is something I describe in detail in the article Leading remote teams: rituals that actually work.

During this phase, pay particular attention to quiet signals. Is the person asking fewer questions than at the beginning because they have understood everything, or because they no longer dare to? Remotely, you won’t see it in their face at the coffee machine. So ask directly in the 1:1 whether there are things that are still unclear but now “feel weird to ask”. This phrasing opens a door surprisingly often.

The 30-day conversation

After one month, a dedicated conversation that goes beyond the regular 1:1 is worth it. It has two goals: finding out how the new person is doing, and learning how to improve your onboarding. These questions work well as a framework:

What helped you most during the first weeks?
When did you first feel like part of the team?
What surprised you, positively or negatively?
Which question haven’t you dared to ask so far?
What should we do differently in the next onboarding?
What do you need from me over the next 60 days?

The answers to the second-to-last question are pure gold. Write them down and adjust your remote onboarding checklist accordingly. That way, onboarding gets a little better with every new team member.

Common mistakes in remote onboarding

The most common mistake is a first week made up of nothing but forms, mandatory training and documentation. All of that is necessary, but if nobody has asked the new person how they are doing by Friday, one feeling sticks above all: here, I am just a case file.

A second classic is “Let me know if you need anything”. It is meant kindly. In practice, though, it puts all the responsibility on the person who knows least about what they need and whom they can ask. Scheduled meetings and the get-to-know-you list solve this better.

Third: too much at once. Anyone who gets twelve intro calls, three training sessions and the complete architecture explained in the first week retains very little of it. Spread the content across the month and allow time to process what was heard.

And finally: no wrap-up. If onboarding simply fizzles out, you miss the moment when you look back together. The 30-day conversation closes this gap and at the same time gives you the feedback you need for the next onboarding.

My take

I consider onboarding one of the most underrated leadership tasks of all. A lot of energy goes into selecting new people, into job ads and interviews. Once the signature is in, however, things often go quiet, and the first working day becomes a task for the IT department.

Yet you will never again get as much honest feedback about your team as during a new member’s first weeks. New people see what has long become normal for everyone else: unclear processes, outdated documentation, unwritten rules. Make use of that instead of smoothing it over.

I want to push back on the idea that remote onboarding is inherently worse than onboarding in the office. It is different and requires more planning. In return, it forces you to write down things that otherwise only live in people’s heads. In the end, the whole team benefits, not just the new colleague.

FAQ

How long does remote onboarding take?

For actually settling in, 30 days is a good frame. Until someone works truly independently within the team, it takes considerably longer depending on the role. So keep regular 1:1s going after the first month as well.

What belongs in a remote onboarding checklist?

At a minimum: hardware and access before day one, a pre-planned calendar for week one, an onboarding buddy, a get-to-know-you list, a small first task with pairing and a wrap-up conversation after 30 days.

How often should an onboarding buddy check in?

A proven rhythm: one call on day one, two more in the first week and at least one more until the end of the month. Ask the new person whether this pace suits them.

Who is responsible for onboarding?

The manager is responsible and plans the framework. The buddy, the team and the new person shape it together. Organizational matters such as hardware and accounts can be handled by IT or HR.

Your next step

Take the checklist and go through it for the next person who joins your team. If nobody is starting right now, ask the team member who joined most recently: what would have helped you during your first 30 days? The answers will show you very precisely where your onboarding has gaps today.

I’m curious how you handle it: what was the best thing that happened to you in a remote onboarding? Feel free to share it in the comments.

Continue the series: Back to the “Leadership in brief” overview · Previous part: Leading remote teams with rituals that work. Next part: Offboarding: when someone leaves the team.

📄 Printable cheat sheet – The complete 30-day remote onboarding checklist to tick off – with buddy rhythm and questions for the 30-day conversation. Download PDF · View online

Sources

This post was created with AI assistance.

👉 Next step: Preparing a first one-on-one? My question cheat sheet puts the best questions on one printable page.

Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en

Deleting files safely from a Tauri app: what I learned sending them to the Windows Recycle Bin from Rust

Dare — Sat, 31 Oct 2026 17:49:15 +0000

I'm building a disk cleaner for Windows in Rust and Tauri 2. Finding junk isn't the scary part. Deleting it is. If the scanner has a bug, you see a wrong number. If the delete path has a bug, someone loses files.

So the delete path ended up with more code and more tests than anything else in the app. Here's what it does and why. All the snippets are from the real source, trimmed a bit, with the file name on top.

One thing up front: not everything my app removes goes to the Recycle Bin. I'll get to that at the end, because I only fixed how the UI talks about it this week.

1. The webview only gets to delete what a scan returned

In Tauri the UI is a webview calling Rust commands. I treat it like any other client I don't control. If a command takes a list of paths, those paths could be anything.

So the backend remembers what each scan returned, and only those paths can be trashed:

// src-tauri/src/files/guard.rs (simplified)
type Approved = HashMap<ScanKind, HashSet<String>>;
static APPROVED: LazyLock<Mutex<Approved>> = LazyLock::new(Mutex::default);

/// Records the files a scan returned to the UI: only these can be trashed.
/// Protected paths are never recorded.
pub fn approve<'a>(kind: ScanKind, paths: impl IntoIterator<Item = &'a str>) {
    let set = paths
        .into_iter()
        .filter(|path| !is_protected(Path::new(path)))
        .map(str::to_owned)
        .collect();
    approved().insert(kind, set);
}

trash_files checks every path against that set. Anything else is reported as failed and left alone. There's a test for it: a file no scan returned gets reported, and it's still on disk afterwards.

2. "Inside C:\Windows" means folder boundaries

The protected list is what you'd expect. %SystemRoot%, Program Files and ProgramData. $Recycle.Bin and System Volume Information anywhere. pagefile.sys, Recovery, Windows.old and friends at a drive root. Network shares get refused too.

The comparison is where it's easy to slip. A plain starts_with thinks c:\windowsill\notes.txt is inside c:\windows. So paths get normalised first (no \\?\ prefix, lower case, no trailing separator) and then compared on folder boundaries:

// src-tauri/src/files/guard.rs
/// `c:\data` contains `c:\data\x` but not `c:\database`.
pub fn is_within(path: &str, root: &str) -> bool {
    match path.strip_prefix(root) {
        Some("") => true,
        Some(rest) => root.ends_with(SEP) || rest.starts_with(SEP),
        None => false,
    }
}

Yes, there's a test for C:\Windowsill\notes.txt.

3. A path can change between the scan and the delete

By the time someone clicks "Move to Recycle Bin", the scan might be minutes old. In that time a folder on the path could have been swapped for a junction pointing somewhere else. Scans return resolved paths, so right before deleting I resolve the path again and refuse it if it doesn't resolve to itself anymore:

// src-tauri/src/files/guard.rs
/// A regular file (not a link or folder) outside protected locations whose path
/// resolves to itself. A link or junction put in the way since the scan is refused.
fn safe_size(path: &str) -> Option<u64> {
    let meta = Path::new(path).symlink_metadata().ok().filter(std::fs::Metadata::is_file)?;
    let real = normalize(&std::fs::canonicalize(path).ok()?);
    (real == normalize(Path::new(path)) && !is_protected_normalized(&real)).then_some(meta.len())
}

On Windows canonicalize also expands 8.3 short names like PROGRA~1, which is one more way two strings can mean the same folder. The check runs again for every batch, right before Windows sees the paths, since an earlier batch might have sat on a dialog for a while.

4. The `trash` crate and COM threads

The actual move is done by the trash crate (5.x). On Windows it initialises COM single-threaded. My app already had other commands (the program list, icons) setting COM to multithreaded on the shared command threads. Call trash on one of those and you don't get an error. You get a panic.

The fix is boring. Every Recycle Bin operation gets its own thread:

// src-tauri/src/recycle.rs
/// `trash` initialises COM single-threaded and *panics* when the thread already uses
/// the multithreaded model. A new thread has no COM state, and a panic there only
/// fails this call.
pub fn on_own_thread<T: Send + 'static>(f: impl FnOnce() -> T + Send + 'static) -> Option<T> {
    std::thread::spawn(f).join().ok()
}

If you've got windows-crate COM code and trash in the same Tauri app, it's worth checking which thread each one runs on.

5. Batches, cancels, and "delete permanently?"

One shell operation per file is slow. One giant operation fails as a whole if a single path is bad. I went with batches of 64, and if a batch fails before it even starts, the code falls back to one file at a time so one bad path doesn't hold up the rest.

Windows has opinions too. If a file is too big for the Recycle Bin, Windows asks whether to delete it permanently. If the user says no, I shouldn't ask again for every remaining file:

// src-tauri/src/files/guard.rs (simplified)
const TRASH_BATCH: usize = 64;
const USER_CANCELLED: [i32; 2] = [
    0x8007_04C7_u32 as i32, // HRESULT_FROM_WIN32(ERROR_CANCELLED)
    0x8027_0000_u32 as i32, // COPYENGINE_E_USER_CANCELLED
];

for chunk in paths.chunks(TRASH_BATCH) {
    let chunk: Vec<&String> = chunk.iter().filter(|p| safe_size(p).is_some()).collect();
    match trash::delete_all(&chunk) {
        Ok(()) => {}
        Err(err) if cancelled_by_user(&err) => return, // the user stopped it
        Err(trash::Error::Unknown { .. }) => {}        // ran, but the shell skipped some
        Err(_) => { /* failed before starting: retry one by one */ }
    }
}

6. Let the disk say what moved

The shell's return value doesn't tell you what happened to each file. So after the move, the code just looks. If a path still exists, it's a failure. Only paths that are actually gone count toward "bytes freed":

// src-tauri/src/files/guard.rs
// The file system is the source of truth for what actually moved.
for (path, size) in targets {
    if exists(&path) { report.failed.push(path); }
    else { report.bytes_freed += size; report.deleted.push(path); }
}

That's why the number the app shows can be smaller than what you picked. Files that were in use stay put and show up as failed.

7. Being honest about what doesn't go to the Recycle Bin

This is the part I got wrong.

Large files, duplicates and similar photos go through everything above. Dev build folders (node_modules, target and so on) also go to the Recycle Bin, through a similar check in recycle.rs. Temp files and caches don't. The cleanup rules in junk_rules/mod.rs delete them with std::fs::remove_file, and the confirm text says why: "These are caches and temporary files; apps rebuild them as needed." What they get instead is a couple of different guards. A rule is skipped while its app is running (the comment in the code: "deleting a live cache can corrupt it"), and One-Click Fix and the scheduler only touch files older than 24 hours.

The code was fine with that. My welcome screen wasn't. It told people deleted files go to the Recycle Bin, which just isn't true for caches.

This week (#103) I swapped the native confirm box for an in-app dialog. It lists what's about to go and shows one of two labels: "Can be restored from the Recycle Bin" or "Permanent â€” not moved to the Recycle Bin". Cancel has focus by default. The welcome text now says: "Super Cleaner always asks first. Large files go to the Recycle Bin; caches and temp files are deleted for good."

While I was in there I found 11 of my 26 confirms showing English buttons in the Chinese UI. Turns out that one was on me. My old confirmAction() wrapper defaulted to okLabel = "Continue" and cancelLabel = "Cancel", hardcoded in English, and 11 call sites never passed their own labels. Now okLabel is required and Cancel defaults to the translated string.

If you're writing your own delete path

Don't trust the UI with paths, and only delete what the backend found itself. Normalise before you compare, compare on folder boundaries, and resolve again right before the delete. If anything else in your process touches COM, give trash its own thread. Assume the user, or Windows, will cancel halfway. Count what's actually gone from the disk. And tell people plainly what they can and can't undo, because that's the part I almost shipped wrong.

The code's from Super Cleaner, a Windows cleaner I'm building in Rust + Tauri. It's not public yet. I'll post here when it is.