Validation

Full test suite: 211/211 passed (test_kanban_db.py).

Also validated in production on a multi-task pipeline (hermes-android-mvp board):

• ✅ kanban_complete preserves workspace files (no silent deletion)
• ✅ archive_task cleans up scratch directory and nulls out workspace_path
• ✅ dir workspace writes directly to project root — no extra file copying needed
• ✅ Existing done tasks unaffected; dir/worktree workspaces unchanged

Closing in favor of #41352, which fixes #33774 with a smaller, targeted change: scratch workspaces are deferred (not deleted) while linked children are active, then swept once all children are terminal. Your approach (never delete on completion, only on archive) changes the scratch lifecycle contract more broadly — the disk-growth tradeoff there is a separate product decision we'd rather handle on its own. Appreciate the thorough writeup on the silent-deletion problem; it helped frame the fix. Thanks!

Closing in favor of #41352, which fixes #33774 with a smaller, targeted change: scratch workspaces are deferred (not deleted) while linked children are active, then swept once all children are terminal. Your approach (never delete on completion, only on archive) changes the scratch lifecycle contract more broadly — the disk-growth tradeoff there is a separate product decision we'd rather handle on its own. Appreciate the thorough writeup on the silent-deletion problem; it helped frame the fix. Thanks!

Hey Teknium,

This isn't really about a specific PR.

Over the last week I've been experimenting with building a kanban-centric software development / issue-fixing workflow around Hermes. During that process I've gone through roughly 3B tokens,

contributed a handful of small PRs (mostly around usability, visibility, and workflow improvements), and spent a lot of time reading related issues and discussions.
sth like this.

One thing I've started noticing is that several seemingly unrelated problems actually feel connected.

The scratch workspace discussion is what made me realize it.

After reading through #28818, #33774, #33916, #38454, #41352 and the related user reports, I think the engineering side of the problem is fairly clear. #41352 solves the parent-child handoff issue without changing the overall workspace lifecycle, which makes sense as a focused fix.

What I found more interesting was the user feedback.

The recurring theme wasn't really "I disagree with auto-deletion."

It was closer to:

"I didn't realize this workspace would be deleted."

That distinction feels important.

From an engineering perspective, "scratch" often implies temporary or disposable storage. But looking at the reports, many users seem to interpret it as "create a new workspace from scratch" rather than "create a workspace that will be automatically removed later."

The docs are clear. The tip exists.

Yet multiple users still independently arrive at the same misunderstanding.

To me, that's usually a sign that the issue is less about documentation and more about how information is surfaced during the workflow itself.

One other observation that might be relevant:

I suspect the Hermes audience today may be broader than many of us assume.

A growing number of users seem to be coming from AI-assisted development workflows rather than traditional software engineering backgrounds. Some are vibe coders, product builders, founders, designers, or people who learned programming through AI tools rather than through conventional engineering environments.

For those users, terms like "scratch" may not naturally imply disposable storage.

The more common interpretation is often simply:

"start from scratch"

— a fresh workspace, not a temporary one.

I also noticed that parts of the Kanban experience remain untranslated for non-English users. In those cases, users may see the raw term "scratch" without any additional context in their native language. That makes the mental-model gap even more understandable.
like German

What's interesting is that I've noticed a similar pattern elsewhere too.

Many of the usability improvements I've worked on recently weren't really about adding new capabilities.

They were about making existing system state more visible at the moment users make decisions.

That's why I no longer think the most interesting question here is whether scratch should auto-delete or not.

The more interesting question, at least to me, is whether users are building the same mental model of the system that Hermes expects them to have.

Anyway, I don't have a strong proposal here. I just wanted to share an observation from the perspective of a very heavy user who is trying to build real development workflows around Hermes.

For what it's worth, Hermes is one of the most interesting agent systems I've used, which is exactly why I've spent so much time thinking about these things.