0.12.0's herdr leftovers are not both inert

[blooop]

Retrospective wf-review of #376 (which merged unreviewed — Sourcery was out of quota) found the retraction itself sound: I independently reproduced a real git revert -m 1 and confirmed nothing from #369's --rm grammar or #374's hostname change was undone. What is wrong is one paragraph of the CHANGELOG, and it is wrong in the direction that matters.

The hook is inert as dl now runs, not unconditionally

0.12.0 says:

Two leftovers, both inert. … Neither does anything: the hook returns immediately without the variables aid no longer sets

True of dl. But HERDR_ENV, HERDR_PANE_ID and HERDR_SOCKET_PATH are herdr's own variables, not dl's — and the replacement the same entry recommends one paragraph earlier is herdr --remote <workspace-id>.devpod, which sets all three itself. So the leftover ~/.devlaunch/herdr-agent-state.py wakes up and resumes reporting agent state from a dl that no longer has anything to say about it. #367 established that a reported state overrides herdr's native detection and does not decay, so a stale report can pin a badge the remote server would otherwise have got right.

The entry recommends the exact thing that un-inerts the leftover it calls inert.

The socket mount was never inert

It is a capability the container still holds. 0.8.0's README said what it grants:

Mounting the socket gives the container control of your herdr session — it is the same socket herdr's own CLI drives, so something in there could open panes or read other panes' output.

That sentence was deleted with the feature. The mount was not — it lands at creation and leaves at creation, so every container created while 0.8.0–0.11.0 was installed still has it, with the disclosure gone and DEVLAUNCH_NO_HERDR no longer read, so it cannot be turned off after the fact either. dl <ws> recreate is the only thing that removes it.

Calling that "inert" in the same breath as the hook is the part worth correcting: a reader who upgrades to 0.12.0 reasonably concludes there is nothing to do.

What this changes

CHANGELOG only, plus one unrelated README count. The rewritten entry:

• leads with the fact that neither leftover is removed by upgrading, and that dl <ws> recreate is the action
• keeps "inert" for the hook but scopes it, and names herdr --remote as what wakes it
• states the mount as a surviving capability and quotes 0.8.0's own disclosure back

Also

README.md:836 said naming the container "is the one stage today". setup_stages (provision.rs:989-1030) builds three: hostname unconditionally, zellij under ToolsSwitch::Install + ZellijSwitch::Install, and the terminal title under Some(title). #376 fixed the in-code sibling counts (039d8bc) and missed the README's. Pre-existing — it predates #367.

Not fixed here

The review's third finding: the diagnostic defect that motivated the whole retraction — a stage's stderr explaining why it failed is discarded, only the exit status becomes a ProvisionEvent — still applies to every remaining stage (provision.rs:1945). That is already #377, filed 13 minutes after #376 merged, and it is the highest-value item still outstanding here.

Verified

pixi run -q python -m pytest test/ --ignore=test/e2e: 20 failed / 283 passed, byte-identical to pristine main in this scratch clone (the failures all need a built dl binary, which CI has and a fresh clone does not). No test changes: this is documentation, and the claims it corrects were checked against provision.rs, git show abc64d9:README.md for the deleted disclosure, and #367's reported-state-overrides-native semantics.

🤖 Generated with Claude Code

Summary by Sourcery

Clarify the behavior and cleanup requirements of legacy herdr leftovers, and align the README with the current provisioning stage count.

Bug Fixes:

• Correct the 0.12.0 changelog to clarify that legacy herdr hooks can become active again under remote sessions and that stale reports may override native state detection.
• Correct the changelog to document the persistent herdr socket capability and explain that recreating affected workspaces is required to remove it.
• Fix the README description of provisioning stages to reflect that hostname, zellij configuration, and terminal title can comprise three stages.

Documentation:

• Update user-facing release notes with accurate remediation guidance and the security implications of leftover herdr artifacts.

[sourcery-ai]

Sorry @blooop, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[sourcery-ai]

Reviewer's Guide

Refines the 0.12.0 documentation around herdr-related leftovers and provisioning stages, clarifying that upgrading does not remove certain artifacts, that one leftover hook can become active again under herdr remote usage, that an old socket mount remains a live capability until workspace recreation, and correcting the README’s description of the current setup stages.

Flow diagram for removing legacy herdr leftovers

flowchart TD
    A[Workspace created with 0.8.0-0.11.0] --> B[Upgrade to 0.12.0]
    B --> C[Legacy hook remains]
    B --> D[Socket mount remains]
    C --> E{herdr --remote session?}
    E -->|No| F[Hook is inert as dl now runs]
    E -->|Yes| G[Hook reads HERDR_ENV, HERDR_PANE_ID, and HERDR_SOCKET_PATH]
    G --> H[Reported agent state can pin the badge]
    D --> I[Container retains control of the herdr session]
    C --> J[dl <ws> recreate]
    D --> J
    J --> K[Legacy hook and socket mount are removed]

Loading

Flow diagram for current provisioning stages

flowchart TD
    A[Setup pass] --> B[Hostname stage]
    B --> C{Zellij switch enabled?}
    C -->|Yes| D[Zellij configuration stage]
    C -->|No| E{Terminal title configured?}
    D --> E
    E -->|Yes| F[Terminal title stage]
    E -->|No| G[Probe]
    F --> G

Loading

File-Level Changes

Change	Details	Files
Clarify behavior and risks of herdr agent hook and socket mount leftovers in workspaces created under versions 0.8.0–0.11.0, and explicitly document the need to recreate those workspaces after upgrading.	Rewrite the CHANGELOG entry to emphasize that both the herdr agent hook and socket mount persist across upgrades and are only removed by dl <ws> recreate. Explain that the herdr agent hook is inert under current dl behavior but becomes active again when using herdr --remote <workspace-id>.devpod, potentially pinning stale state badges. Restore and quote the previous README disclosure about the herdr socket mount’s capability, and state that it remains effective for existing containers and cannot be disabled post-creation except via workspace recreation. Clarify that DEVLAUNCH_NO_HERDR is no longer read, while DEVLAUNCH_NO_TOOLS still applies to the rest of provisioning.	CHANGELOG.md
Correct README documentation of the number and conditions of setup stages executed during the devpod setup pass.	Update the README to state that there are currently three setup stages (hostname, zellij config, terminal title) instead of one. Document that the hostname stage always runs, while zellij and terminal title stages are conditional on their respective switches being enabled. Clarify that these stages share the same trip as the probe, so they do not incur extra round trips.	README.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.21%. Comparing base (a5f7ed8) to head (73eea6a).

Additional details and impacted files

Flag	Coverage Δ
python	42.98% <ø> (ø)
rust	95.57% <ø> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
shipped code (rust)	95.57% <ø> (+0.02%)	⬆️
harness and tooling (python)	42.98% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.