resolved 258d5227-5a33-4b7f-aa96-3bea75ffa1c6
requirements, specification, local_public_data_packagesPromote latent package-interoperability requirements uncovered during local public-data package implementation into requirements/glossary source records only.
Scope: edit only records/req./.md and records/term./.md, then run npm test, npm run build:syrs, and npm run build:glossary. Do not modify runtime code, CLI/PWA/package fixtures/conformance/Rust/TypeScript/WASM/closeout reports/deployment artifacts, or package authoring guide except generated docs from build commands.
Required requirement record updates:
Required glossary updates:
Acceptance: tests/builds pass; generated SyRS and glossary include the requested concepts; no package authoring guide modification.
Commit 3c27156 addresses all three rejected polish items and is pushed to main. The generated SyRS/glossary are rebuilt, verification commands passed, and local main, gitlab/main, and remote main all point at 3c2715697b5b0fc1ed0b39a4763dd3aee22ddb3c with a clean single worktree.
Intake phase complete. The operator tool surface was confirmed with tools/list, the ticket was created and fetched for full context, and the worktree was checked. Implementation phase will edit only requirement and term source records, then run npm test, npm run build:syrs, and npm run build:glossary.
Implementation phase complete. Requirement records were amended for package validation context, fixture discovery, fixture expectation truth, approval-visible inspection facts, trust/capability enforcement, exact local public-data capability identifiers, NoFallback requested implementation behavior, package-generic APIs, non-fabricated request/output snapshots, artifact availability by CID codec and role, resource-limit report semantics, Station Profile publication, and package-generic authoring surfaces. Added BENAC-PKG-011 plus glossary terms for package validation context, fixture discovery source, and artifact availability. Verification phase will run npm test, npm run build:syrs, npm run build:glossary, and generated-output concept checks.
Verification phase complete. npm test, npm run build:syrs, and npm run build:glossary all passed. Generated SyRS checks found the required concepts for validation context, fixture discovery, document-only context-required checks, fixture expectation truth, approval-visible inspection facts, trust/capability enforcement, rejected legacy capability identifiers, NoFallback, artifact availability by CID codec/role, non-fabricated request/output snapshots, resource-limit deny-operation versus deny-record behavior, and package-generic surfaces. Generated glossary checks found Package validation context, Fixture discovery source, and Artifact availability. Only requirement/term source records and generated SyRS/glossary outputs were changed by this ticket; unrelated pre-existing worktree changes remain untouched.
Caller rejected: Yeah — mostly yes. The maintainer did the important thing: the latent semantics are now actually in the generated SyRS/glossary instead of being trapped in the implementation ticket, conformance history, or tribal memory.
I would call this substantively correct, with a few cleanup edits before we treat it as fully closed. Tiny bit of “measure twice before publishing the authoring guide” energy here.
The big fixture/CID-cycle issue is now captured. BENAC-PKG-007 explicitly says fixtures may be external to the package document so they can bind to the final package CID without creating a package-CID cycle, and that bundle manifests, capsule document sets, imported distribution context, or package-document fixture refs may supply the discoverable fixture set. It also says bundle/capsule/imported validation fails local-public-data packages with no discoverable fixtures, while package-document-only validation must report the check as not evaluated/context-required rather than silently passing it .
The validation-context distinction is now in the requirements. BENAC-AUTHOR-001 now requires validation to identify whether it is package-document-only, package bundle, capsule, imported Station state, or another distribution context, and it says context-required checks must not be silently reported as passed when the context is absent . BENAC-AUTHOR-003 also now requires validation/build reports to include validation context, distribution context references, fixture discovery source/status, context-required checks not evaluated, and artifact availability resolution status .
The build-ordering issue is captured too. BENAC-AUTHOR-002 now says build shall produce the package document and package CID first, then stamp/bind/assemble fixture records referencing that package CID, then assemble the bundle/capsule context, and then validate the resulting distribution context. That directly addresses the package-CID/fixture-CID cycle problem .
The fixture truth problem is now explicit. BENAC-TEST-002 says invocation success alone shall not make a fixture pass, and that fixture execution must evaluate declared expectations including selected implementation, expected output, diagnostic codes, denied effects, evidence/effect classes, raw diagnostic evidence behavior, and resource-limit behavior . BENAC-TEST-003 then requires fixture result records to carry the expectation-evaluation summary and observed-versus-expected fields, and says pass/fail derives from expectation evaluation rather than invocation status alone . That one is important. Good catch, good requirement.
The approval/inspection truth problem is also captured. BENAC-UX-009 now says local public-data approval cannot rely on hidden bundle/capsule facts absent from the referenced inspection result, and it requires approval to identify whether the inspection context was package-document-only, bundle, capsule, or imported Station state .
The trust/capability enforcement gap is now in the requirements, not just code-review notes. BENAC-TRUST-003 now says trust decision scope is an authority boundary, invocation fails closed outside that scope, and effective capabilities are the intersection of selected implementation requirements, trust-decision allowed capabilities, active grants, and Local Policy . BENAC-TRUST-006 also now makes local public-data approval enforceable only within recorded package, implementation/selection policy, descriptor, interface, data-class, and capability scope, and excludes private/credential/secret/high-sensitivity data classes unless another approval profile exists .
The capability vocabulary cleanup is now explicit. BENAC-CAP-007 names the baseline identifiers, says aliases/synonyms/host-local names are not accepted, and specifically rejects local_execution and local_blob_read_exact as baseline local public-data capabilities . That is exactly the kind of thing that prevents independent package authors from shipping packages that only work on one host.
The no-fallback and trace-integrity rules landed. BENAC-EXEC-008 now says the default fallback policy for requested implementations is NoFallback, and requested missing/unsupported/unavailable implementations must fail unless explicit recorded fallback policy exists . BENAC-INV-005 reinforces that Benac shall not silently switch requested package, implementation, descriptor, interface, trust scope, capability scope, data class, storage source, compute source, schema ruleset, or security behavior . BENAC-INV-008 now forbids fabricated request/output snapshots during trace reconstruction/export/inspection/replay .
Artifact availability is now a first-class requirement. BENAC-PKG-011 was added and correctly distinguishes raw blob CIDs from structured document CIDs, saying availability resolution must depend on artifact role and CID codec, not only blob-store presence . BENAC-UX-008 also carries the same inspection-side rule: structured DRISL document CIDs are checked against document availability or bundle/capsule document sets, while raw blob CIDs are checked against blob availability .
The resource-limit semantics are much sharper now. BENAC-WASM-004 now covers validation, build, fixture execution, ordinary invocation, and WASM/declarative execution, and it requires reports to say whether a breach denied the whole operation or only the offending record. It also defines the baseline behavior for oversized logs/evidence/effects continuing only when the denied record is not required for output, fixture expectation, approval evidence, or audit requirement .
The glossary work is also in place. The generated glossary now includes Package validation context, Fixture discovery source, and Artifact availability, with definitions that match the intended semantics . It also updates Package Bundle to say a bundle may provide authoritative distribution context for external schemas, artifacts, fixtures, reports, inspection results, documentation, and claims, and that bundle-carried fixtures may be required without changing the package CID . Local public-data approval and Resource limit report also got the enforcement/resource-reporting glosses we wanted .
The only real semantic cleanup I see is in BENAC-PKG-007 verification. It still contains this older broad sentence:
“A package claiming local public-data portable package compatibility without required fixtures fails package validation.”
That is now too imprecise because the same requirement correctly says package-document-only validation should report fixture discoverability as context-required instead of treating it as passed or failed. I would change that old sentence to:
“A package claiming local public-data portable package compatibility without discoverable required fixtures fails package bundle, capsule, or imported-distribution-context validation.”
That keeps it from accidentally contradicting the new document-only validation semantics .
Second, I’d lightly tighten BENAC-CAP-007. It currently says unknown/unsupported/out-of-scope capability identifiers fail closed “unless a separate explicit authorization record grants them,” and then later says retired identifiers are rejected. That is probably okay, but for package authors I’d make it impossible to misread. I’d add one sentence:
“Such separate authorization shall not make an unregistered identifier an alias for a baseline local public-data capability.”
That prevents someone from treating local_blob_read_exact as “authorized by another record” rather than retired.
Third, the glossary still says a Package Bundle contains a “package manifest,” while the newer requirements consistently use “package document” as the identity-bearing object. Not fatal, but I’d align the term:
“An importable/exportable collection containing a package document and selected related schemas…”
That will make the authoring guide cleaner and reduce “manifest vs document” drift .
Fourth, the generated glossary source section for the three new terms says “Required glossary changes” . That smells like ticket-section text leaking into generated docs. Not semantically bad, but I’d prefer a stable source section name like “Package authoring and validation terminology.”
Yes: the requirements update was done right enough to move forward, assuming the source records were actually edited and the generated files were produced by npm run build:syrs and npm run build:glossary.
I would not block the authoring guide on major missing requirements anymore. I’d do the three or four small cleanup edits above, rebuild SyRS/glossary, and then write the package authoring guide from these records. The core latent requirements are now captured.
Rejection review phase complete. I fetched the full ticket with get_ticket and confirmed the human resolution_rejected event. The requested cleanup is scoped to four SyRS/glossary issues: narrow BENAC-PKG-007 validation wording, clarify BENAC-CAP-007 alias handling, align Package Bundle wording from manifest to package document, and replace the leaked Required glossary changes source section with stable terminology-section wording. Cleanup implementation will stay within requirement/term source records plus regenerated SyRS/glossary outputs.
Cleanup implementation phase complete. Updated BENAC-PKG-007 verification to fail missing discoverable fixtures only for package bundle, capsule, or imported-distribution-context validation; added the BENAC-CAP-007 sentence preventing separate authorization from turning unregistered identifiers into baseline aliases; changed Package Bundle to contain a package document; and changed the three new glossary term source sections to Package authoring and validation terminology. Verification phase will regenerate SyRS/glossary outputs and run the requested checks.
Verification phase complete. npm test, npm run build:syrs, and npm run build:glossary all passed. Targeted checks confirm the generated SyRS now contains the narrowed BENAC-PKG-007 validation sentence and BENAC-CAP-007 alias sentence, and the generated glossary now says Package Bundle contains a package document and uses Package authoring and validation terminology for the three new term source sections. Commit/push phase will keep this ticket's changes limited to source records and regenerated SyRS/glossary outputs.
Repository reconciliation phase starting. The cleanup edits and requested verification have passed on the feature branch, and the branch now contains a separated docs/records commit instead of the rejected mixed release commit. Next I am fast-forwarding main to include the scoped SyRS/glossary work, then I will verify main and propose resolution only after main and gitlab/main are current.
Repository reconciliation phase complete. The scoped SyRS/glossary cleanup is merged into main, local main and gitlab/main both point at 8ba57c9, the single /srv/benac worktree is clean on main, and the temporary mixed-release backup branch was removed.
Caller rejected:
In BENAC-CAP-007:
“Unknown capability identifiers, unsupported capability identifiers, or capabilities outside the local public-data package scope shall fail closed unless a separate explicit authorization record grants them.”
That is close, but it leaves a little wiggle room where someone could read it as “unknown capability identifiers can be granted by an authorization record.” The next sentence helps, but I’d make it sharper.
I would change it to something like:
Unknown or unregistered capability identifiers shall fail closed and shall not be authorized by local public-data package approval. Capabilities outside the baseline local public-data package scope require a separately defined approval profile or extension profile and explicit authorization. Such authorization shall not make the capability a baseline local public-data capability or an alias for any registered baseline identifier.
That preserves the possibility of extension profiles without accidentally allowing mystery strings into baseline package authority. Tiny wording thing, but it matters.
Also, BENAC-AUTHOR-002 still uses “package manifest logical object” in one place, then “package document” elsewhere. Since package identity is the DRISL-encoded package document, I’d standardize that phrase to package document logical object.
Finally, the glossary term Package Artifact still says artifacts “usually live in the Blob Store.” That’s technically okay because it says “usually,” but now that BENAC-PKG-011 explicitly allows structured document artifacts, I’d add a sentence saying package artifacts may be raw blobs or structured documents depending on artifact role and CID codec.
Second rejection review phase complete. The caller rejected the proposed resolution with three polish items: sharpen BENAC-CAP-007 so unknown or unregistered capability identifiers cannot be authorized by local public-data package approval, rename the remaining BENAC-AUTHOR-002 package manifest logical object phrase to package document logical object, and update the Package Artifact glossary term to say artifacts may be raw blobs or structured documents depending on artifact role and CID codec. Implementation will stay within those source records plus regenerated SyRS/glossary outputs.
Second cleanup implementation phase complete. BENAC-CAP-007 now says unknown or unregistered capability identifiers fail closed and cannot be authorized by local public-data package approval, while out-of-baseline capabilities require a separate approval or extension profile and explicit authorization without becoming baseline capabilities or aliases. BENAC-AUTHOR-002 now says package document logical object. Package Artifact now states that package artifacts may be raw blobs or structured documents depending on artifact role and CID codec. Verification phase will regenerate SyRS/glossary outputs and run the requested checks.
Second polish implementation phase complete. Updated BENAC-CAP-007 to fail unknown or unregistered identifiers closed and forbid local public-data approval from authorizing them, changed BENAC-AUTHOR-002 to package document logical object, and added raw blob or structured document wording to Package Artifact. Verification phase will regenerate SyRS and glossary outputs and run the requested checks.
Second polish verification phase complete. npm test passed, including regenerated glossary, regenerated SyRS, and dataset validation. Explicit npm run build:syrs and npm run build:glossary also passed. Targeted checks confirm the generated SyRS contains the sharpened BENAC-CAP-007 wording and package document logical object wording, the generated glossary contains the Package Artifact raw blob or structured document wording, no package manifest logical object phrase remains in records or generated docs, and git diff --check is clean. Commit and push phase will keep the scope to the three source records plus regenerated SyRS/glossary outputs.
Second polish commit and push phase complete. Committed the scoped source-record and generated SyRS/glossary changes as 3c27156 and pushed main to gitlab. Final reconciliation phase will verify local main, gitlab/main, the remote main ref, and worktree cleanliness before proposing resolution.
Second polish resolution proposed. Implemented the caller three remaining polish items in commit 3c27156 pushed to main: BENAC-CAP-007 now says unknown or unregistered capability identifiers fail closed and cannot be authorized by local public-data package approval, with out-of-baseline capabilities requiring a separately defined approval or extension profile and explicit authorization without becoming baseline capabilities or aliases; BENAC-AUTHOR-002 now uses package document logical object; Package Artifact now states artifacts may be raw blobs or structured documents depending on artifact role and CID codec. Regenerated docs/01-Requirements/System-Requirements-Specification.md and docs/00-Glossary/Terms-and-Definitions.md. Verification passed: npm test, npm run build:syrs, npm run build:glossary, targeted rg checks, and git diff --check. Final reconciliation shows local main, gitlab/main, and remote refs/heads/main all at 3c2715697b5b0fc1ed0b39a4763dd3aee22ddb3c, the single /srv/benac worktree is clean on main, and no runtime or deployment artifacts were modified.
Caller accepted the proposed resolution.
Sign in as a human to drive this ticket from the page, or use the MCP tools.
Ticket created: Promote package interoperability requirements into SyRS records