ReachWeaver 0.7.0 release notes

Released on 2026-10-17.

Four new offline commands (trace, media-cutlist, seo-destinations --suggest-for, multi-account draft), Instagram and Threads token-expiry reminders in health, two dashboard fixes, and PyPI publishing without a manual approval. No change to approval, dry-run, emergency-stop or credential rules.

Upgrade notes. None needed. Update the package with pipx upgrade reachweaver and the plugin through /plugin.

Changed

• PyPI upload no longer waits for a manual approval. The pypi environment has no required reviewer (owner decision, 2026-10-17). A v* tag push that passes verify and publish now uploads the already-checked wheel and sdist to PyPI. The other guards are unchanged: tag-only environment, owner-only actor check, PYPI_PUBLISH switch, checksum verification. docs/PACKAGING.md says how to restore the approval.

Added

• Token-expiry reminders for Instagram and Threads in health. health, ops-summary and the dashboard Overview now report instagram_authorization_warning/threads_authorization_warning 7 days before the recorded authorization_expires_at, and _expired after it, as they already did for LinkedIn. Before, only doctor said so, and the send preflight refused an expired token. While the capability registry keeps the adapter manual-only (today’s bundled default), an expired token is attention, not blocked, because nothing can be sent with it, and a missing expiry is not reported. Once the owner enables the adapter after a live receipt, an expired token blocks readiness and a missing expiry is flagged, like LinkedIn. The dashboard explains the LinkedIn, Instagram and Threads authorization codes in plain language. The token value is never read; no send, approval or credential rule changed.
• reachweaver trace POST_ID: one post’s story in one place (issue #26). It prints the post’s audit events from the database and, with --log FILE (or --log - for journalctl ... -o cat output), the worker-log lines that name it plus the start and end lines of those runs, oldest first, with a one-line summary such as “Published after 1 send attempt(s)”. Read-only: the database is opened mode=ro and never created; nothing is sent, retried or contacted. A worker log is untrusted input: only lines with the worker-log schema version and a known event are used, only allow-listed fields are kept, every value is redacted, oversized lines are skipped and counted, and symbolic links or oversized files are refused. See worker operations.
• seo-destinations --suggest-for PLATFORM: how to point each platform’s post at the landing page. For every platform asked (repeat the flag), it adds the link to use (UTM-tagged with --campaign) and suggestions on where to put it, length, the page’s keyword, tags and alt text. Each suggestion is labelled official (a provider rule, with its source and the date it was checked, e.g. Threads’ 5-link and one-topic-tag limits), unverified (no official statement found, e.g. Instagram and TikTok caption links, so use the profile link), repo_policy or hypothesis (editorial advice). None claims a reach or ranking effect, and a test enforces that wording. Offline: it reads only the briefs file. Output without the flag is unchanged. See SEO integration.
• media-cutlist PLAN.json: one master video, a cut list per platform. Describe the master (length, frame size, focus point) and mark segments with a priority. For Shorts, TikTok, Instagram, LinkedIn, Bluesky and Mastodon it says which segments fit the platform’s sourced maximum duration, the crop window for the target aspect around the focus point, the subtitle format and size limit, and a suggested ffmpeg command (shell-quoted, documented filters only) for you to run. Limits carry their official source and checked date; one the source does not establish is flagged unverified; an owner max_s can only shorten a cut; crops are scaled down, never up. Nothing is opened, cut, encoded or uploaded, and ReachWeaver does not run the command. See media assets.
• draft can create one draft per account in one go. Repeat --account (up to 20) and the same text becomes one separate draft row per account, all or none: the text is checked against each account’s platform limits and opt-out list first, and if any account fails, nothing is created and every problem is listed. Each draft still needs its own show and approve; nothing is approved, scheduled or sent together. Two accounts on the same platform are refused (identical text there reads as duplicate posting), and --reply-to still takes exactly one account. With one --account, behaviour and output are unchanged.

Fixed

• Dashboard: the “Files and approvals” card now reports a database, approval ledger or archive that other users of the computer can read, with the chmod to fix it. The folder check has always found these; the 0.6.0 card dropped them, although its documentation said otherwise (found in an independent review).
• Dashboard: a sent post no longer reads as “never approved”. The approval details of a sending, published or needs_review post showed binding: not_approved, because show only re-checks the binding while a post waits to be sent. The page now says “not re-checked after the send started”. The show and API output are unchanged.