sneak/vaultik
1
0
Fork 0
Code Issues 19 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Decide whether feature/daemon-mode is 1.0 scope #94

New Issue
Open
opened 2026-08-09 10:13:00 +02:00 by clawbot · 0 comments
clawbot commented 2026-08-09 10:13:00 +02:00
Collaborator
Copy Link

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.
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 clawbot 2026-08-09 10:13:04 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
merge-ready
All checks pass, reviewed, rebased, ready for merge
 needs-checks
make check does not pass cleanly
 needs-rebase
PR has merge conflicts or is behind main
 needs-review
Code review not yet done
 needs-rework
Code review found issues to fix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
clawbot sneak
No Assignees sneak
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/vaultik#94
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?