refactor(dynseal): one copy of the subsystem, not two and a half #10

Merged

peterswimm merged 1 commit from fix/consolidate-dynseal into main

2026-09-28 19:57:51 +00:00

forge-ci commented

2026-09-28 19:56:35 +00:00

Member

Stage 1 of reviving dynseal. Consolidation only — no behaviour change, and
nothing touches the database.

Why

dynseal was in three places:


`dynseal/`	the current modules
`docs/dynseal/`	a second copy of all thirteen — twelve byte-identical, one 77 lines apart
`docs/dynseal_server.py`	the Flask server the whole thing runs on

…and docs/ also carried byte-identical copies of both shell scripts.

The divergent file is the point. dynseal/'s publisher calls
_assert_dynseal_schema; docs/dynseal/'s still calls _init_dynseal_tables.
That is the schema-first move — DDL belongs in migrations, service code asserts
presence — caught half-done, with the old version preserved beside the new one
and nothing to say which was which. The copy dropped here is the older one.

What this unblocks, measured

Two files named test_security_scenarios.py in directories with no
__init__.py are a pytest import collision. Before:

ERROR docs/dynseal/test_security_scenarios.py
!!!!!! Interrupted: 1 error during collection !!!!!!
no tests collected, 1 error

After: collection completes cleanly. It still finds zero tests, because the
class is SecurityScenarioTester rather than Test* — a separate fix, later in
this series — but the collector no longer aborts, which is what stopped the
whole directory from being reachable at all.

A pre-existing bug, written down rather than fixed

start-dynseal-server.sh initialises ./data/foundation.db relative to the repo
root, while the server opens <its own directory>/data/foundation.db. Those
have never been the same file, so that block has never initialised the database
the server uses.

Moving the server changes which wrong path it is, not whether it is wrong. It
is left alone and commented: the schema-first conversion removes both sides, and
aligning a SQLite path on its way out is work with a shelf life.

Testing

pytest --collect-only dynseal/ — aborts before, clean after (above).
tools/check_schema_registry.py — still reports the registry consistent.
bash -n start-dynseal-server.sh — clean.
git records all five moved files as R100 renames, so history follows them.
The server's PATTERNS_DIR and DB_PATH derive from its own location and are
both mkdir'd at startup; neither previously existed on disk, so the move
breaks nothing.

Impact Statement

Breaking changes: none. No module's contents change. Five files move, one
superseded copy and two duplicated scripts are removed, and one path reference
plus the README are updated.

Risk. The only external-facing change is that start-dynseal-server.sh now
runs dynseal/dynseal_server.py. Anyone invoking python3 dynseal_server.py
from docs/ by hand will need the new path; the README is updated to match.

What this does not do: revive anything. dynseal still cannot run — its
forge_root is hardcoded to a directory that no longer exists, and it asserts a
SQLite schema while naming a Postgres migration. Those are the next stages.

Stage 1 of reviving dynseal. Consolidation only — no behaviour change, and nothing touches the database. ## Why dynseal was in three places: | | | |---|---| | `dynseal/` | the current modules | | `docs/dynseal/` | a second copy of all thirteen — **twelve byte-identical**, one 77 lines apart | | `docs/dynseal_server.py` | the Flask server the whole thing runs on | …and `docs/` also carried byte-identical copies of both shell scripts. **The divergent file is the point.** `dynseal/`'s publisher calls `_assert_dynseal_schema`; `docs/dynseal/`'s still calls `_init_dynseal_tables`. That is the schema-first move — DDL belongs in migrations, service code asserts presence — caught half-done, with the old version preserved beside the new one and nothing to say which was which. The copy dropped here is the older one. ## What this unblocks, measured Two files named `test_security_scenarios.py` in directories with no `__init__.py` are a pytest import collision. Before: ``` ERROR docs/dynseal/test_security_scenarios.py !!!!!! Interrupted: 1 error during collection !!!!!! no tests collected, 1 error ``` After: collection completes cleanly. It still finds **zero** tests, because the class is `SecurityScenarioTester` rather than `Test*` — a separate fix, later in this series — but the collector no longer aborts, which is what stopped the whole directory from being reachable at all. ## A pre-existing bug, written down rather than fixed `start-dynseal-server.sh` initialises `./data/foundation.db` relative to the repo root, while the server opens `<its own directory>/data/foundation.db`. **Those have never been the same file**, so that block has never initialised the database the server uses. Moving the server changes *which* wrong path it is, not whether it is wrong. It is left alone and commented: the schema-first conversion removes both sides, and aligning a SQLite path on its way out is work with a shelf life. ## Testing - `pytest --collect-only dynseal/` — aborts before, clean after (above). - `tools/check_schema_registry.py` — still reports the registry consistent. - `bash -n start-dynseal-server.sh` — clean. - git records all five moved files as `R100` renames, so history follows them. - The server's `PATTERNS_DIR` and `DB_PATH` derive from its own location and are both `mkdir`'d at startup; neither previously existed on disk, so the move breaks nothing. ## Impact Statement **Breaking changes: none.** No module's contents change. Five files move, one superseded copy and two duplicated scripts are removed, and one path reference plus the README are updated. **Risk.** The only external-facing change is that `start-dynseal-server.sh` now runs `dynseal/dynseal_server.py`. Anyone invoking `python3 dynseal_server.py` from `docs/` by hand will need the new path; the README is updated to match. **What this does not do:** revive anything. dynseal still cannot run — its `forge_root` is hardcoded to a directory that no longer exists, and it asserts a SQLite schema while naming a Postgres migration. Those are the next stages.

forge-ci added 1 commit

2026-09-28 19:56:36 +00:00

refactor(dynseal): one copy of the subsystem, not two and a half

PR policy check / policy-gate (pull_request) Failing after 0s

Details

CI / schema-registry (pull_request) Successful in 5s

Details

ed03470d2b

dynseal was in three places. `dynseal/` held the current modules. `docs/dynseal/`
held a second copy of all thirteen — twelve byte-identical, and
`dynseal-pattern-publisher.py` 77 lines apart. `docs/` also held the Flask
server the whole thing runs on, plus its own copies of both shell scripts.

The divergent file is the point. `dynseal/`'s publisher calls
`_assert_dynseal_schema`; `docs/dynseal/`'s still calls `_init_dynseal_tables`.
That is the schema-first move — DDL belongs in migrations, service code asserts
presence — caught half-done, with the old version preserved beside the new one
and nothing to say which was which. The copy being dropped is the older one.

WHAT THIS UNBLOCKS, measured rather than asserted. Two files named
test_security_scenarios.py, in directories with no __init__.py, are a pytest
import collision. Before:

  ERROR docs/dynseal/test_security_scenarios.py
  !!!!!! Interrupted: 1 error during collection !!!!!!
  no tests collected, 1 error

After: collection completes cleanly. It still finds zero tests, because the
class is named SecurityScenarioTester rather than Test* — that is a separate
fix — but the collector no longer aborts, which is what stopped the whole
directory from ever being reachable.

Also folded in, because they were the same duplication: `docs/` carried
byte-identical copies of start-dynseal-server.sh and test-dynseal-api.sh. One of
each remains, at the repo root, where DYNSEAL_README.md already points.

A pre-existing bug is left ALONE and written down instead. The start script
initialises ./data/foundation.db relative to the repo root, while the server
opens <its own directory>/data/foundation.db. Those have never been the same
file, so that block has never initialised the database the server uses. Moving
the server changes which wrong path it is, not whether it is wrong. The
schema-first conversion removes both sides; aligning a SQLite path on its way
out would be work with a shelf life.

No behaviour change otherwise. The server's PATTERNS_DIR and DB_PATH are derived
from its own location and both are mkdir'd at startup; neither previously
existed on disk, so the move breaks nothing.

Verified: pytest collects dynseal/ without error where it previously aborted;
`tools/check_schema_registry.py` still reports the registry consistent; the
start script passes `bash -n`; git records all five moved files as renames.

peterswimm merged commit 937c318697 into main

2026-09-28 19:57:51 +00:00

peterswimm deleted branch fix/consolidate-dynseal

2026-09-28 19:57:51 +00:00

peterswimm referenced this pull request from a commit

2026-09-28 19:57:52 +00:00

Merge pull request 'refactor(dynseal): one copy of the subsystem, not two and a half' (#10) from fix/consolidate-dynseal into main

forge-ci referenced this pull request

2026-09-28 20:44:05 +00:00

feat(dynseal): the server asserts its schema instead of inventing one #11