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.