Skip to content

feat(prototype): check bound documents for leaks, and filter the queue by type - #124

Merged
AndrejK666 merged 1 commit into
constructorfabric:mainfrom
AndrejK666:AndrejK666/analyse-from-the-queue
Sep 11, 2026
Merged

feat(prototype): check bound documents for leaks, and filter the queue by type#124
AndrejK666 merged 1 commit into
constructorfabric:mainfrom
AndrejK666:AndrejK666/analyse-from-the-queue

Conversation

@AndrejK666

Copy link
Copy Markdown
Contributor

Two things from the Documents queue.

1. Leak, run from the place that knows the type

A stage can gate on any detector, but only purpose was ever recorded against a
bound file — so a stage gating on leak could never complete from this flow.

leak belongs here for a reason the service itself enforces: it refuses a
document whose type it has not been told —

422  "doc type unknown: pass doc_type, or a path naming the type
      (PRD.md, DESIGN.md, ADR/0001-x.md, features/y.md)"

— because "foreign content" means nothing until you have said what native
content would be. A bound document has a type. Nothing is guessed, and nothing
is inferred from a filename.

It runs over the documents that have a type and writes the verdict both places,
as the purpose run does: the finding to the graph, the pass/fail to the binding,
which is what the gate reads.

It runs unverified, and that was measured

The service verifies its own candidates with an LLM by default, and on this
deployment that pass clears every one of them
. Two documents of known kind,
declared correctly and incorrectly, unverified:

document declared as passed share
a design contract design 0.00
a design contract adr 0.68
a design contract prd 1.00
a real ADR adr 0.00
a real ADR prd 0.99
a real ADR design 0.99

Right type → passes at 0.00. Wrong type → fails, and the share tracks how wrong.

With verification on, all six pass — including the ADR read as a PRD at 0.99
raw. Omitting verify behaves the same as verify: true, which is how the
first few probes came back clean and nearly sent this out as a gate that always
opens.

A check that never fires is not evidence that documents are clean, and a gate
wired to one would open for everything while looking like it had checked. So the
run passes verify: false, and the table lives in the comment on detectLeak
so nobody has to re-measure it.

That also gives the queue a second opinion on its own classification: a document
bound to the wrong type fails its leak check.

2. Not bloat or traceability

They are set-wise: one run over a document set producing duplicates and
traces_to relations, with no per-document verdict anywhere in the response
(materializeSetwise turns them into graph edges, which is all they can be).
Gating a stage on them would mean inventing what "this document passed bloat"
means. They stay in the Analyze tab, where relations are what they are.

3. Filter by type

The queue filtered by state only — needs review, bound, not documents, all. It
now also filters by document type: the types this project's documents actually
are, rather than the whole catalogue, plus the undetermined ones.

tsc -b and the 41 prototype tests clean. Frontend only.

…e by type

Two things from the queue.

## Leak, from the place that knows the type

A stage can gate on any detector, but only `purpose` was ever recorded against a
bound file, so a stage gating on `leak` could never complete from this flow.

`leak` belongs here for a reason the service enforces: it refuses a document
whose type it has not been told — 422, "pass doc_type, or a path naming the
type" — because "foreign content" means nothing until you have said what native
content would be. A bound document has a type. Nothing is guessed.

It runs over the documents that have one, and writes the verdict both places, as
the purpose run does: the finding to the graph, the pass/fail to the binding,
which is what the gate reads.

### It runs unverified, and that was measured

The service verifies its own candidates with an LLM by default, and on this
deployment that pass clears every one of them. Two documents of known kind,
declared correctly and incorrectly, unverified:

                                declared as   passed   share
  a design contract             design        yes      0.00
  a design contract             adr           NO       0.68
  a design contract             prd           NO       1.00
  a real ADR                    adr           yes      0.00
  a real ADR                    prd           NO       0.99
  a real ADR                    design        NO       0.99

With verification on, all six pass — including the ADR read as a PRD at 0.99
raw. A check that never fires is not evidence that documents are clean, and a
gate wired to one would open for everything while looking like it had checked.
So the run passes `verify: false`, and the table is in the code.

That also gives the queue a second opinion on its own classification: a document
bound to the wrong type fails its leak check.

## Not bloat or traceability

They are set-wise: one run over a document set producing `duplicates` and
`traces_to` relations, with no per-document verdict anywhere in the response.
Gating a stage on them would mean inventing what "this document passed bloat"
means, so they stay in the Analyze tab, where relations are what they are.

## Filter by type

The queue filtered by state only. It now also filters by document type — the
types this project's documents actually are, not the whole catalogue, plus the
undetermined ones.

Signed-off-by: Andrej Kuchma <Andrej.Kuchma@constructor.tech>
@coderabbitai

coderabbitai Bot commented Sep 11, 2026

Copy link
Copy Markdown

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 5b24642a-4771-40c7-9463-4cf9d77d6fab


Comment @coderabbitai help to get the list of available commands.

@AndrejK666
AndrejK666 merged commit a89baa5 into constructorfabric:main Sep 11, 2026
3 checks passed
@AndrejK666
AndrejK666 deleted the AndrejK666/analyse-from-the-queue branch September 11, 2026 11:05
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.

1 participant