Skip to content

0.1.0a8 — the dependency signal, and what it refuses to claim - #19

Closed
FlagshipDev wants to merge 1 commit into
mainfrom
publish/2026-08-09-2a0665a
Closed

0.1.0a8 — the dependency signal, and what it refuses to claim#19
FlagshipDev wants to merge 1 commit into
mainfrom
publish/2026-08-09-2a0665a

Conversation

@FlagshipDev

Copy link
Copy Markdown
Contributor

What this release makes reachable that was not before.

A second signal

Hullwork verifies which of the things your tools claim are actually true. Until now it did that for
one signal: a production error becomes a failing test, then a fix, then a draft pull request. This
release adds the second.

hullwork deps --checkout . reads the versions your lock files pin, asks OSV what is published
against those exact versions, and prints what came back. No credential of any kind — no forge, no
model, no database. The one host it contacts takes no key and no account.

--verify then answers the question nobody else does: it applies each published fix in a sandbox
and runs your own test suite against it. The verdict is ranked by what it asks of a person —
fix your suite first, needs work, blocked, ready to take — worst first.

--open opens a draft pull request for the ones that passed, one per package, never a batch, and
never anything else. --fix asks an agent to change your code so an upgrade that breaks your suite
fits, without being allowed to touch your dependency files.

What it refuses to claim, which is most of the point

The claim on a verified upgrade is exact: your suite passed before this change and passes after
it.
Never "safe", never "this fixes the vulnerability". A suite that does not exercise the
dependency stays green without ever loading the new version, and the pull request says so.

And it says no more often than yes. Measured on four real third-party repositories before this
release: one clean verdict. The rest could not be measured at all — a suite that reaches the network
a sandbox denies by design, a pin in a file the image does not install from, an image the project
brings ready-made. Each is reported as what it is, with the reason and what to change, rather than
verified wrongly.

hullwork features

New, and it answers before you have decided anything: feature by feature, whether this can serve
your project, which requirement is missing when it cannot, and what it will not do even when it
can
. No credential, no container, no socket, nothing written.

The Sentry webhook route

Enabled. Authenticated by the token in its URL — the same credential a GlitchTip route has, checked
the same way, because GlitchTip cannot sign its webhooks at all. Sentry's signature is not
verified
, and SECURITY.md says once, for both providers, what that does not cover: anyone who
obtains the URL can post to it. Treat it as a secret; hullwork projects rotate-secret replaces it.

A number about itself

hullwork status and the page now report what arrived and how much of it left a person's desk with
evidence attached — including a row for what Hullwork put on that desk rather than took off it.
That row is the one this product can be embarrassed by, and it is printed above the others.

One new manifest field

autofix.open_upgrades, false by default. Opening a verified upgrade as a pull request is the first
thing a project can refuse while Hullwork is able to do it: having a capability is not the same as
having agreed to it. Every other default in that block already refuses.

Note that a manifest carrying this field is rejected by earlier releases, which forbid unknown
fields by design. A project that does not set it is unaffected.

Fixed

  • A verified-green verdict could be produced for a version that was never installed — twice, by two
    different routes: a pin in a file outside runtime.dependencies, and install: none, which is
    the default. Both are now refused before a container is built, with the reason and the remedy.
  • A fix phase that created test configuration where a project had none could switch the suite
    off and publish with the mechanism inside its own diff. The guard against editing that
    configuration had never covered inventing it.
  • deps --verify did not hand the source to the image build, so any project whose installer reads
    its own files could not be verified at all.
  • Requirements files outside a root requirements.txt were not read: requirements/prod.txt,
    requirements-dev.txt and their shape were invisible, and the report said nothing about the gap.
  • Agent runs discovered a missing model credential, and a missing gateway image, at the most
    expensive possible moment. Both are answered in under a second now.

Still true, and worth reading before relying on any of it

Nobody outside this project has installed Hullwork. Every measurement in this release was taken by
the people who wrote it. docs/status.md is the honest scope and it changes weekly.

Signed-off-by: Javier Miralles Rancaño 68760931+FlagshipDev@users.noreply.github.com

What this release makes reachable that was not before.

## A second signal

Hullwork verifies which of the things your tools claim are actually true. Until now it did that for
one signal: a production error becomes a failing test, then a fix, then a draft pull request. This
release adds the second.

`hullwork deps --checkout .` reads the versions your lock files pin, asks OSV what is published
against those exact versions, and prints what came back. No credential of any kind — no forge, no
model, no database. The one host it contacts takes no key and no account.

`--verify` then answers the question nobody else does: it applies each published fix in a sandbox
and runs **your own test suite** against it. The verdict is ranked by what it asks of a person —
fix your suite first, needs work, blocked, ready to take — worst first.

`--open` opens a draft pull request for the ones that passed, one per package, never a batch, and
never anything else. `--fix` asks an agent to change your code so an upgrade that breaks your suite
fits, without being allowed to touch your dependency files.

## What it refuses to claim, which is most of the point

The claim on a verified upgrade is exact: *your suite passed before this change and passes after
it.* Never "safe", never "this fixes the vulnerability". A suite that does not exercise the
dependency stays green without ever loading the new version, and the pull request says so.

And it says **no** more often than yes. Measured on four real third-party repositories before this
release: one clean verdict. The rest could not be measured at all — a suite that reaches the network
a sandbox denies by design, a pin in a file the image does not install from, an image the project
brings ready-made. Each is reported as what it is, with the reason and what to change, rather than
verified wrongly.

## `hullwork features`

New, and it answers before you have decided anything: feature by feature, whether this can serve
your project, which requirement is missing when it cannot, and **what it will not do even when it
can**. No credential, no container, no socket, nothing written.

## The Sentry webhook route

Enabled. Authenticated by the token in its URL — the same credential a GlitchTip route has, checked
the same way, because GlitchTip cannot sign its webhooks at all. **Sentry's signature is not
verified**, and `SECURITY.md` says once, for both providers, what that does not cover: anyone who
obtains the URL can post to it. Treat it as a secret; `hullwork projects rotate-secret` replaces it.

## A number about itself

`hullwork status` and the page now report what arrived and how much of it left a person's desk with
evidence attached — including a row for what Hullwork **put on** that desk rather than took off it.
That row is the one this product can be embarrassed by, and it is printed above the others.

## One new manifest field

`autofix.open_upgrades`, false by default. Opening a verified upgrade as a pull request is the first
thing a project can refuse while Hullwork is able to do it: having a capability is not the same as
having agreed to it. Every other default in that block already refuses.

Note that a manifest carrying this field is rejected by earlier releases, which forbid unknown
fields by design. A project that does not set it is unaffected.

## Fixed

- A verified-green verdict could be produced for a version that was never installed — twice, by two
  different routes: a pin in a file outside `runtime.dependencies`, and `install: none`, which is
  the default. Both are now refused before a container is built, with the reason and the remedy.
- A fix phase that **created** test configuration where a project had none could switch the suite
  off and publish with the mechanism inside its own diff. The guard against editing that
  configuration had never covered inventing it.
- `deps --verify` did not hand the source to the image build, so any project whose installer reads
  its own files could not be verified at all.
- Requirements files outside a root `requirements.txt` were not read: `requirements/prod.txt`,
  `requirements-dev.txt` and their shape were invisible, and the report said nothing about the gap.
- Agent runs discovered a missing model credential, and a missing gateway image, at the most
  expensive possible moment. Both are answered in under a second now.

## Still true, and worth reading before relying on any of it

Nobody outside this project has installed Hullwork. Every measurement in this release was taken by
the people who wrote it. `docs/status.md` is the honest scope and it changes weekly.

Signed-off-by: Javier Miralles Rancaño <68760931+FlagshipDev@users.noreply.github.com>
Comment thread tests/test_webhooks.py
assert item.lane_reason and "payment" in item.lane_reason, (
f"the culprit did not reach triage; the lane defaulted: {item.lane_reason!r}"
)
assert item.permalink and "sentry.io" in item.permalink

assert desk.left_with_evidence == 1, "only the one with a verdict behind it"
assert desk.arrived == 2
del theirs
Comment thread hullwork/dispatch.py
import logging
import shutil
import tempfile
from collections.abc import Callable, Sequence
@FlagshipDev

Copy link
Copy Markdown
Contributor Author

Reemplazado por #20: CodeQL puso tres alertas sobre código de este PR y las tres están resueltas allí — una era real (del innecesario), y las otras dos son clases que el item 161 ya había documentado como falsas. Ninguna se ha silenciado.

@FlagshipDev FlagshipDev closed this Aug 9, 2026
@FlagshipDev
FlagshipDev deleted the publish/2026-08-09-2a0665a branch August 9, 2026 17:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants