stack/docs/plans/reviews/2026-09-06_foundation-inspector-filbert-verdict.md

# FI-FILBERT-2 — independent frozen-charter review

Reviewer: filbert. Author/integrator: darkwing. Contributor: rocko.
Follow-up owner: darkwing. Date: 2026-09-06.

## Admission and verdict

**NOT APPROVED for implementation-charter readiness.** The bounded inspector is
plausibly implementable without a new dependency or live runtime, but the frozen
algorithm needs the three substantive clarifications below before code authorization.
This is a written specification verdict, not a reproduced implementation failure.

Admission remains compatible: no competing current personal owner-authorized
assignment appeared. I did not author/co-author either input. I treated Rocko's
note as contributor material, not his approval of darkwing's integration. Charter
corrections take precedence over incorporated note sections 5–13.

Exact inputs independently hashed:

- `docs/plans/2026-09-06_foundation-inspector-charter.md`, candidate 2:
  `cbd0487a2ab699722924e2f91367bf556facb015752ce3b5a76ad474977df791`
- `docs/plans/reviews/2026-09-06_foundation-inspector-rocko-feasibility-r2.md`:
  `f2f47fcfe22dca79f10f885b83d87a2f846fdb560425a4e20705c40ce4a123e1`
- Accepted map: `7345f330fc6bfae5aa1d896c78cfb7cbe62efbae`.
- Source/plan baseline: `d4696d09eb1b5dcf1028f30db2cd63735f51cb16`.

The first two are frozen uncommitted files, not blobs falsely attributed to the
source baseline. Source comparisons used `git show` at the specified commits.

## Numbered findings

### 1. Blocking / high — consulted registration delegation has no semantic gate

**Locations:** charter §§3–4, especially current registration/delegation references
and adoption of L1–L9; incorporated r2 §§6.2–6.3 and §7 L2/L3. Baseline candidate
README:73–78,128–136; records.schema.json `$defs/registrationPayload` and
`$defs/decisionPayload`.

The registration's `delegationRef` may be non-null. The specified rules require
that it resolve, name a head, and have the record kind `decision`. L2/L3 then check
registration status, role ceiling and narrowing. They do not say that the referenced
decision must be an approved, applicable delegation, or what a rejected/revoked or
unrelated decision does to the registration's simulated admission.

Concrete witness to specify: an otherwise valid active registration points to a
current rejected delegation decision, or to a current plan-approval/acceptance
about unrelated work. All its role/policy layers permit file.read. Exact reference
resolution and active registration status alone do not reject these cases under
the listed algorithm. They must not silently become a permitted preview of current
authority. Charter §5's proposal delegation checks do not cover ordinary L2/L3
registration use.

**Independent evidence:** a baseline valid registration mutated to reference the
valid fixture's non-delegation decision remains JSON-Schema-valid. This was an
isolated shape probe, not an executed inspector or complete graph demonstration.
It establishes that the schema cannot supply the missing semantic check.

**Required correction:** define the simulation semantics of non-null registration
delegation references, including applicable kind/outcome/recipient/scope bounds and
revocation/current-decision behavior. Keep null/owner-origin registration assumptions
explicit. Add coherent positive and rejected/unrelated/current-revoked negatives
that reach that semantic gate. No actual authentication or signature verification
is requested for this offline slice.

### 2. Blocking / high — cross-scope work-reference admission is underspecified

**Locations:** charter §3:88–95 and §4; incorporated r2 §6.2:222–227 and §7 L8.
Accepted map:250–269; baseline candidate README:57–71.

The baseline requires task mission/dependency references to resolve to **permitted
work**, with cross-scope access distinct from membership and execution authority.
The incorporated graph rule only says a task's mission resolves in the “selected
project.” The charter adds accepted status for same-project dependencies before
file.change, but does not define access checks for work in another workspace of
that project. “Dependencies grant no ownership/access” is not an algorithm for
checking whether the referenced work is permitted.

Concrete witnesses:

- Agent A is registered only in W1. Its selected W1 task names an active mission,
  or an accepted dependency task, in W2 of the same project. All named records and
  declarations exist. The listed same-project/status checks can succeed without
  any check of A's permission to use that W2 work reference.
- An unselected historical/current task in P2 has a legitimate P2 mission while
  selection names P1. If “selected project” is a global structural graph constraint,
  this legitimate separate project is rejected. If it means each task's owning
  project/context, the specification should say so. This matters to a bundle with
  multiple projects and the new original/target requester contexts.
- A dependency in another project is said not to lend permission and broader
  execution semantics are unsupported, but the exact admission result for that
  reference is not stated. It must not simply be omitted from readiness checks.

**Independent evidence:** a valid baseline task mutated to name a mission in a
different workspace of the same project remains JSON-Schema-valid. No cross-scope
permission resolver was run or claimed; this is a missing specified semantic rule.

**Required correction:** distinguish per-record structural ownership from per-caller
consulted-reference access. Define the supported mission/dependency scope relations,
visibility/admission checks, and refusal for out-of-slice references, with exact
rule/exit outcomes. Add coherent same-project-unregistered-workspace and unrelated-P2
inventory tests. Resolve this within the bounded model, not by implementing real
authentication or expanding into a runtime dependency engine.

### 3. Blocking / medium — delegation-chain refusal lacks an observable predicate

**Locations:** charter §3 declaration limits and §5:133–135; incorporated r2
§§5.2,6.2,8; baseline decisionPayload and artifactRef definitions.

The charter promises “Unmodelled delegation chains refuse unsupported-capability.”
The closed proposal supplies one delegationRef. A decision has subjectRefs and an
artifact basis, but no typed parent-delegation field. Declared artifacts contain only
runId/artifactId/digest; the inspector never reads their bodies. The specification
does not define a subjectRef to another decision as a delegation-parent relation
(subject references otherwise explicitly support history).

Consequently an implementation cannot determine that an otherwise well-shaped
delegation relies on a chain hidden behind its declared basis. Adding an arbitrary
parent field would instead fail the unknown-field structural rule, not reach the
promised unsupported-capability gate. Treating every referenced decision as a parent
would invent a relation and can misclassify historical subjects.

**Required correction:** state exactly what observable input denotes an unsupported
chain and its precedence, or explicitly delimit the model to direct declared
delegation assumptions and withdraw any claim to detect hidden chains. Define tests
for the chosen supported/unsupported distinction. Do not infer trust from artifact
presence or add an undocumented parent relationship during coding.

### 4. Nonblocking / medium — cycle fixtures need explicit within-graph precedence

**Locations:** charter §3:88–90 and A3; incorporated r2 §§6.2–6.3,12.3,13.

The global stages are ordered, but ownership/parent-scope/continuity checks versus
cycle checks within the graph stage are not. A mission cycle necessarily violates
the permitted workspace-to-project parent structure; a supersedes cycle necessarily
violates the immediately preceding revision rule. Either can therefore be caught
by another semantic guard before the cycle detector.

**Independent evidence:** a workspace mission with a self-parent and a revision-2
task with self-supersedes both pass the record schema. Thus cycle tests can reach
a semantic detector if it precedes the other graph guards; they are not inherently
impossible. After successful parent-scope/continuity checks, those cycle cases cannot
reach a distinct cycle outcome.

**Disposition / requested clarification:** freeze the graph sub-order or document
which guard is the intended outcome for each fixture. Use separate detector-unit
and CLI-precedence tests where appropriate. Do not count an earlier wrong-owner or
bad-predecessor refusal as demonstrated cycle-detector coverage. This does not by
itself require a larger implementation scope.

### 5. Nonblocking / low — strengthen differential coverage beyond the listed mutations

**Locations:** charter §8; incorporated r2 §12.1; pinned checker/schema.

The mandatory independent Python oracle, pinned hashes, no-skip rule, and separation
of schema verdict from inspector-profile/unsupported-kind/graph verdict are valuable
and address drift. The listed mutations do not systematically cover scalar type
substitution, all null/absence branches, numeric bounds/boolean-versus-integer cases,
object-order-insensitive uniqueness, or non-BMP character-count boundaries.

**Disposition / recommendation:** include those boundaries in the deterministic
corpus, particularly because the Node validator is handwritten. Numeric 1.0 is a
valid schema integer but forbidden as an inspector input token; retain separate
entry paths for those tests. A passing finite corpus is compatibility evidence,
not proof that all candidate-schema behavior has been implemented.

## Review-question dispositions

| Question | Disposition |
|---|---|
| Coherent, implementable, faithful, ready for code authorization? | Not yet: findings 1–3 require design resolution. The dependency-free offline architecture itself is feasible in principle. |
| Exact types, subset, history, mandatory/optional layers | Reference types, eight-kind subset, explicit execution layer and null narrowing are sound. Complete-history versus consulted-head distinction is materially improved. Registration delegation and cross-scope reference semantics remain incomplete. |
| Requester contexts and reassignment | Both requester contexts correctly apply all L1–L9 rather than just memberships. Subject/selection binding, approved task intent and no reassignment success are clear. Delegation-chain behavior needs finding 3 resolved. No mock basis/auth ID is treated here as authentic evidence. |
| Privacy, output, exits, number/Unicode domains | Revised closed output removes inventory/count disclosure; null pre-validation fields, fixed prose, JSON disclaimer field and escaped text are sensible. Numeric lexical profile is distinct from schema semantics. Clarify cycle precedence per finding 4 and test those output rules rather than just exit codes. |
| Filesystem and no-effect limits | Proposed descriptor-based Linux boundary is implementable; final-component symlink protection is not parent containment. O_CLOEXEC correction, quiescent-input limitation and no proof-of-no-reads caveats are honest. No descriptor behavior was tested in this review. |
| Differential verification and fixture reachability | Mandatory oracle/hashes and separated validation layers are sound. Findings 4–5 qualify reachability and coverage. Existing fixtures are shapes, not a coherent permission graph. |
| Small first slice / gates | Still offline and bounded, but already includes a full historical graph and substantial handwritten validation. Resolve the above rather than having the coder invent semantics. Written approval, implementation authority, code review and Jason's demo remain separate gates. |

## Independently measured receipts and limits

1. `sha256sum` of both frozen files matched the exact requested hashes.
2. `git show d4696d09:<candidate path>` read schema/fixtures/checker. Independent
   SHA-256 matched records.schema.json
   `05774aaf6943cb69c113e39ff1c29676a2a230ca7bf665c50dbcaa8049672af6`
   and check.py
   `82564a7d3200afcdda0850a9454cac6e6cd6a76687d2162c13cf214d7eac4607`.
   Temporary copies: `/tmp/fi-filbert-2.XdSfM8/`.
3. Inline Python using existing jsonschema 4.26.0 ran five schema-shape probes from
   copied committed fixtures: cross-workspace mission reference; mission self-cycle;
   revision-2 self-supersedes; registration pointing to non-delegation decision;
   numeric revision 1.0. **All five schema-valid, assertions passed, exit 0.** These
   deliberately show where separate semantics/profile checks are required. Custom
   calendar/path format callbacks were not exercised by these probes; their existing
   fixture dates/paths were unchanged. No complete bundle or inspector execution is
   claimed.
4. Inline Python `json.dumps(sort_keys=True,separators=(',',':'))` plus SHA-256
   independently recomputed V1–V3: all matched, exit 0:
   - V1 `0bc44e14fd8354a8a85be879306a54881da7a0cb4d3dcf1f88bc4bc08a40dc9c`
   - V2 `63817bffc57803ca6ac5df971aa0a160d4be73646394b3bc536578bd66c82660`
   - V3 `d538c865808cfe7665956615fb48f69819baa0833626d1ef6e1cb3614acbc7da`
5. `node -e` read Node constants and parsed synthetic numeric strings. Observed
   **Node v26.8.1**, O_RDONLY=0, O_NOFOLLOW=131072, O_NONBLOCK=2048,
   O_CLOEXEC absent. `1.0` parses as 1, `-0` preserves negative zero, and
   `9007199254740993` rounds to `9007199254740992`. This supports exact lexical
   checking before Number conversion. O_RDONLY availability must not be tested by
   truthiness because its valid value is zero. No file-open/symlink/FIFO behavior
   was measured; constants alone are not enforcement evidence.

No proposed code exists to test. I did not run the proposed differential bridge,
CLI, non-effect harness, five repository suites or foundation author checker in
this FI-FILBERT-2 cycle. Earlier FM-FILBERT-1 receipts are not relabelled as new
execution. No dependencies, native/sync tests, engines, live runtime, credentials,
installations, commits, pushes, source changes or ~/.mosaic investigation occurred.
Only this offered verdict path was written in the repository. No charter fix or
co-authorship was performed. Follow-up and any revised candidate remain darkwing's;
this verdict authorizes no implementation or phase advancement.