Skip to content

backlog: close the demand-gate triage (#172 declined, #156 deferral confirmed) #315

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
wshallwshall merged 1 commit into from
Aug 11, 2026
Merged

backlog: close the demand-gate triage (#172 declined, #156 deferral confirmed) #315

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/BACKLOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2027,7 +2027,7 @@ lane; demand-gated on a first enterprise Windows/AD deployment.

## 156. Alert hysteresis (separate fire/clear thresholds)

> 🔢 **Re-scored 2026-08-03 → DEMAND-GATE.** Value **2/10** · Difficulty **3/10** · _fill-in_. Anti-flap refinement the shipped `realert_seconds` / per-rule `cooldown_seconds` throttle already damps (`messagefoundry/config/settings.py:2678`, `:2823`), with single-sided `min_depth`/`min_oldest_seconds` matching confirmed at `messagefoundry/pipeline/alert_sinks.py:617-623`; two new AlertRule fields plus clear-edge state in the sink, no store or migration.
> 🔢 **Re-scored 2026-08-03 → DEMAND-GATE.** Value **2/10** · Difficulty **3/10** · _fill-in_. Anti-flap refinement the shipped `realert_seconds` / per-rule `cooldown_seconds` throttle already damps (`messagefoundry/config/settings.py:2678`, `:2823`), with single-sided `min_depth`/`min_oldest_seconds` matching confirmed at `messagefoundry/pipeline/alert_sinks.py:617-623`; two new AlertRule fields plus clear-edge state in the sink, no store or migration. **Reviewed 2026-08-10 -- deferral stands, and this is the cleanest deferral in the set.** Its trigger names an observation nobody can make yet: *operators reporting flapping the flat realert/cooldown throttle does not damp*. That cannot fire from analysis, only from watching real alerts misbehave. The covering mechanism (`realert_seconds` + per-rule `cooldown_seconds`) is genuine rather than a fig leaf, and building a deadband now means choosing two threshold constants with no traffic to choose them from -- the shape of change that gets tuned once in anger and never revisited.

> **On-trigger / demand-gate.** Numbered for tracking only — build when the trigger below fires (“demand-gate, don’t schedule”).

Expand Down Expand Up @@ -2204,8 +2204,8 @@ lane; demand-gated on a first enterprise Windows/AD deployment.

## 172. Gzip/zip compression codec + file-connector option

> 🔢 **Re-scored 2026-08-03 → DEMAND-GATE.** Value **5/10** · Difficulty **3/10** · _fill-in_. File-feed parity breadth with a clean code-first workaround: the reusable codec shipped including `zip_compress`/`zip_decompress` (`messagefoundry/parsing/compression.py:40-48`), so a zip-delivering partner is served by a Handler call today. What remains is connector-level — widening `_SUPPORTED_COMPRESSION` (`messagefoundry/transports/file.py:88`), which forces an archive-member-to-message decision, plus REMOTEFILE, which has zero compression to extend.
> **On-trigger / demand-gate.** Numbered for tracking only — build when the trigger below fires (“demand-gate, don’t schedule”).
> ⛔ **DECLINED 2026-08-10 -- the remainder is a DECISION, not a gap. The codec SHIPPED; what is declined is auto-extraction on the CONNECTOR.** All six functions (`gzip_compress`/`_decompress`, `zip_compress`/`_decompress`, `deflate_*`) are exported from the TOP-LEVEL `messagefoundry` package, so a Handler compresses or extracts in one line, and binary rides the store via the ADR 0028 `mfb64:v1:` carriage. The connector's `gzip`-only restriction is defended at THREE layers -- the wiring `Literal['gzip'] | None`, `_SUPPORTED_COMPRESSION`, and a validator that raises on `'zip'` -- and those are deliberate: **a gzip is one stream, a zip is an ARCHIVE.** Auto-extracting would make the ingest path decide which member is the message, on a partner-supplied file this project treats as untrusted, with traversal entries and decompression bombs to adjudicate. Two details show the split was designed rather than unfinished: the decompress functions take a `max_output_bytes` BOMB CEILING, and `zip_compress` takes a mapping of NAME to bytes, so an outbound zip needs an entry name only the feed author can choose. **Carried open, this invites someone to remove three guards to 'finish' the item -- and what they would switch on is automatic extraction of partner archives at the front door.**
> **No longer demand-gated -- declined by design. Zip is a Handler job, deliberately.**

> **AMENDED 2026-07-28 — the codec is BUILT; the connector covers gzip only.** Adversarial verification refuted a full close. **BUILT:** the pure three-algorithm compression codec (`messagefoundry/parsing/compression.py`, Handler-callable) and the File connector's gzip/gunzip option ([ADR 0123](adr/0123-compression-codec-gzip-zip-deflate-file-connector-compress-decompress-option.md)).
>
Expand Down
Loading