Skip to content

bug(review): admission path scanner rejects reviewer evidence that cites the service endpoint/port — endpoint-touching candidates are unreviewable #1195

Description

@rafaga2469

Before submitting

  • I searched open and closed issues and did not find a report of this problem.
  • I reviewed this report and removed credentials, tokens, private paths, hostnames, and other sensitive data.

Problem

Reviewer artifact admission deterministically rejects valid lens results whose evidence prose cites the network endpoint or port of the service under review. The admission path scanner classifies slash-bearing tokens such as an host:port publish string or an API route (/v1/...) as repository paths, fails to match them against the frozen path manifest, and refuses the payload:

reviewer artifact admission out_of_scope: reviewer evidence references a path outside the
frozen repository; admission_diagnostic={"code":"evidence_path_out_of_scope",
"location":"PublishPort=127.0.0.1:8100","reason":"unknown_or_malformed_repository_path"}

The reviewer cannot describe findings for a network-facing service without citing its endpoint — the endpoint string is the finding. This makes any candidate touching a published port, API base URL, or service route effectively unreviewable.

Reproduction

  1. Candidate adds a Quadlet service that publishes a port (e.g. PublishPort=0.0.0.0:8100:8100) and exposes HTTP endpoints (/v1/audio/transcriptions, /v1/audio/diarize).
  2. Negotiated v2 START (high risk, 4 lenses), reviewer group capture via host relay.
  3. The review-risk reviewer returns a completed, substantive result whose evidence cites the service endpoint and port (they appear verbatim in the diff: the PublishPort directive and the route constants).
  4. Admission rejects the payload with evidence_path_out_of_scope; the lens slot is not consumed.
  5. Retrying produces the same rejection: the reviewer's evidence legitimately needs the endpoint string. Two consecutive rejections per lineage; the slot can only be closed via capture-unachievable.

Observed triggering tokens across preserved payloads:

  • 127.0.0.1:8100
  • PublishPort=127.0.0.1:8100
  • /v1/audio/diarize
  • :8100/v1/audio/transcriptions
  • Caddy/llama-swap (a component name containing a slash)
  • os.environ/ (LiteLLM env-var indirection syntax)
  • LAN/VPN (plain prose with a slash)

Impact

Across three review lineages on one host, every attempt to review endpoint-touching candidates failed at admission (6+ preserved rejection payloads). Two candidates could only be closed by declaring all lens slots unachievable (relay_transport_bound_exceeded), so they carry no review verdict despite passing their other verification gates.

Expected behavior

The admission path scanner should not treat arbitrary slash-bearing tokens in reviewer evidence prose as repository paths. Suggestions:

  • Only consider a token a path reference if it matches a frozen manifest path or resolves to an existing path prefix (e.g. starts with a known top-level entry).
  • Explicitly ignore well-formed host:port, URL path fragments (/v1/...), and scheme:// tokens.
  • Alternatively, restrict path validation to inspection.paths (which was correct in every rejection) and treat free-text evidence as prose.

Environment

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions