Split out of #71 so the stale-branch triage can proceed without waiting on
a scope decision. This is the only one of the six unmerged branches that
is not resolvable on technical merit.
origin/feature/daemon-mode, tip 87acc05 — "fix: add RunDaemon test,
remove dead daemonWatcherBatchDelay constant". A long-running
daemon/watcher mode with filesystem-change batching. No daemon command
exists on main, the README documents none, and nothing currently
depends on it. So this is unshipped product scope, not a bug fix.
Options
Post-1.0. Delete the branch, file an issue capturing the intent so
the design is not lost, revisit after the tag.
In 1.0. Rebase onto main, bring it up to current interfaces, add
the CLI surface, document it, test it. A substantial work unit that
would meaningfully extend the path to a tag.
Drop entirely. Delete the branch, file nothing.
Recommendation: option 1
The 1.0.0 milestone already carries a security review (#73), two
zero-coverage packages (#66, #73), fault-injection tests (#72), a release
pipeline that does not yet work (#65), and a threat-model question (#81).
Adding a new always-on execution mode expands the surface to be audited
at precisely the point where the goal is to stop expanding it.
A daemon is also the kind of feature that benefits from being designed
against a shipped, tagged baseline — it interacts with the PID lock
(#74 item 5), with cron mode (#84, #87), and with the --json output
contract (#82). Those are all in flight or unresolved; building on them
now means rebuilding later.
Note the branch is not at risk: git keeps it until someone deletes it,
and option 1 explicitly preserves the intent as an issue before deletion.
Definition of done
A decision recorded here with reasoning.
If option 1 or 3: branch deleted, and for option 1 a follow-up issue
filed summarising what the branch did and why it was deferred —
including anything worth salvaging from RunDaemon and the watcher
batching.
If option 2: a definition of done written for the full work unit
(CLI surface, docs, tests, interaction with the PID lock and cron
mode) before any implementation starts.
#71 records the outcome so the branch inventory is complete.
Split out of #71 so the stale-branch triage can proceed without waiting on
a scope decision. This is the only one of the six unmerged branches that
is not resolvable on technical merit.
`origin/feature/daemon-mode`, tip `87acc05` — "fix: add RunDaemon test,
remove dead daemonWatcherBatchDelay constant". A long-running
daemon/watcher mode with filesystem-change batching. No `daemon` command
exists on `main`, the README documents none, and nothing currently
depends on it. So this is unshipped product scope, not a bug fix.
## Options
1. **Post-1.0.** Delete the branch, file an issue capturing the intent so
the design is not lost, revisit after the tag.
2. **In 1.0.** Rebase onto `main`, bring it up to current interfaces, add
the CLI surface, document it, test it. A substantial work unit that
would meaningfully extend the path to a tag.
3. **Drop entirely.** Delete the branch, file nothing.
## Recommendation: option 1
The `1.0.0` milestone already carries a security review (#73), two
zero-coverage packages (#66, #73), fault-injection tests (#72), a release
pipeline that does not yet work (#65), and a threat-model question (#81).
Adding a new always-on execution mode expands the surface to be audited
at precisely the point where the goal is to stop expanding it.
A daemon is also the kind of feature that benefits from being designed
against a shipped, tagged baseline — it interacts with the PID lock
(#74 item 5), with cron mode (#84, #87), and with the `--json` output
contract (#82). Those are all in flight or unresolved; building on them
now means rebuilding later.
Note the branch is not at risk: `git` keeps it until someone deletes it,
and option 1 explicitly preserves the intent as an issue before deletion.
## Definition of done
1. A decision recorded here with reasoning.
2. If option 1 or 3: branch deleted, and for option 1 a follow-up issue
filed summarising what the branch did and why it was deferred —
including anything worth salvaging from `RunDaemon` and the watcher
batching.
3. If option 2: a definition of done written for the full work unit
(CLI surface, docs, tests, interaction with the PID lock and cron
mode) before any implementation starts.
4. #71 records the outcome so the branch inventory is complete.
sneak
was assigned by clawbot2026-08-09 10:13:04 +02:00
option 1. daemon mode seems like a good idea bc of inotify so it can avoid full scans for frequent backups (eg hourly) but other than that it adds little value and in the usual use case where backups are run every 12 or 24 or 36 hours from cron it doesn't really matter.
option 1. daemon mode seems like a good idea bc of inotify so it can avoid full scans for frequent backups (eg hourly) but other than that it adds little value and in the usual use case where backups are run every 12 or 24 or 36 hours from cron it doesn't really matter.
Ruling (sneak, 2026-09-25): option 1. Daemon mode comes after 1.0. Its value is avoiding full scans on frequent backups, such as hourly; for the usual runs from cron every 12 to 36 hours it adds little. The intent and the branch tip are kept in #204; the vaultik manager deletes feature/daemon-mode when it next runs, and closes this issue. Back with clawbot.
Model: opus-5-5
Ruling (sneak, 2026-09-25): option 1. Daemon mode comes after 1.0. Its value is avoiding full scans on frequent backups, such as hourly; for the usual runs from cron every 12 to 36 hours it adds little. The intent and the branch tip are kept in https://git.eeqj.de/sneak/vaultik/issues/204; the vaultik manager deletes `feature/daemon-mode` when it next runs, and closes this issue. Back with clawbot.
Model: opus-5-5
sneak
was unassigned by clawbot2026-09-25 11:54:40 +02:00
clawbot
self-assigned this 2026-09-25 11:54:40 +02:00
Branch feature/daemon-mode (tip 87acc05) deleted per the ruling above. The intent and the tip are kept in #204.
Model: opus-5-5
Branch `feature/daemon-mode` (tip `87acc05`) deleted per the ruling above. The intent and the tip are kept in https://git.eeqj.de/sneak/vaultik/issues/204.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Split out of #71 so the stale-branch triage can proceed without waiting on
a scope decision. This is the only one of the six unmerged branches that
is not resolvable on technical merit.
origin/feature/daemon-mode, tip87acc05— "fix: add RunDaemon test,remove dead daemonWatcherBatchDelay constant". A long-running
daemon/watcher mode with filesystem-change batching. No
daemoncommandexists on
main, the README documents none, and nothing currentlydepends on it. So this is unshipped product scope, not a bug fix.
Options
the design is not lost, revisit after the tag.
main, bring it up to current interfaces, addthe CLI surface, document it, test it. A substantial work unit that
would meaningfully extend the path to a tag.
Recommendation: option 1
The
1.0.0milestone already carries a security review (#73), twozero-coverage packages (#66, #73), fault-injection tests (#72), a release
pipeline that does not yet work (#65), and a threat-model question (#81).
Adding a new always-on execution mode expands the surface to be audited
at precisely the point where the goal is to stop expanding it.
A daemon is also the kind of feature that benefits from being designed
against a shipped, tagged baseline — it interacts with the PID lock
(#74 item 5), with cron mode (#84, #87), and with the
--jsonoutputcontract (#82). Those are all in flight or unresolved; building on them
now means rebuilding later.
Note the branch is not at risk:
gitkeeps it until someone deletes it,and option 1 explicitly preserves the intent as an issue before deletion.
Definition of done
filed summarising what the branch did and why it was deferred —
including anything worth salvaging from
RunDaemonand the watcherbatching.
(CLI surface, docs, tests, interaction with the PID lock and cron
mode) before any implementation starts.
clawbot referenced this issue2026-09-23 13:17:16 +02:00
option 1. daemon mode seems like a good idea bc of inotify so it can avoid full scans for frequent backups (eg hourly) but other than that it adds little value and in the usual use case where backups are run every 12 or 24 or 36 hours from cron it doesn't really matter.
Ruling (sneak, 2026-09-25): option 1. Daemon mode comes after 1.0. Its value is avoiding full scans on frequent backups, such as hourly; for the usual runs from cron every 12 to 36 hours it adds little. The intent and the branch tip are kept in #204; the vaultik manager deletes
feature/daemon-modewhen it next runs, and closes this issue. Back with clawbot.Model: opus-5-5
Branch
feature/daemon-mode(tip87acc05) deleted per the ruling above. The intent and the tip are kept in #204.Model: opus-5-5