Close the last open import pins and the workplan (T04)
interface-canon corrected its Interface and Endpoint pins at 20d7bfc2. Both were pinned twice, to ITC-LAND and ITC-NET, because ITC-LAND section 13.2 lists them in a seed-concept block while the Network Model defines them. Landscape section 13.2 now says in this repository that Interface, Endpoint and API are pointers there and that the Network Model owns the first two, so the next reader does not repeat it. That is the fourth time in one day a list of concept names was read as a definition, after CARING's Scope ladder, CARING's Environment values, and the Landscape seeds that hid SoftwareSystem and SoftwareComponent. The closure section names the pattern. Both boundaries now resolve completely, security-canon 11 of 11 and interface-canon 23 of 23, the registered copy is refreshed to the corrected revision, and validation carries no drift warnings. The CLI test is rebuilt from a deliberately broken copy so that a partner fixing its own pins can no longer break this repository's suite. make check passes with 59 tests, clean validation and no warnings. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 3588@bnt-lap001 Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
This commit is contained in:
parent
44bc71babc
commit
1527b33999
6 changed files with 77 additions and 20 deletions
|
|
@ -4,7 +4,7 @@ type: workplan
|
|||
title: "Make import-manifest name resolution a standing check"
|
||||
domain: infotech
|
||||
repo: info-tech-canon
|
||||
status: active
|
||||
status: finished
|
||||
owner: claude
|
||||
topic_slug: canon-federation
|
||||
created: "2026-09-20"
|
||||
|
|
@ -121,7 +121,7 @@ review starts from a template that asks both questions.
|
|||
|
||||
```task
|
||||
id: INFO-WP-0028-T04
|
||||
status: wait
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "cdf31f69-7a2e-5be0-a988-145dee48c063"
|
||||
```
|
||||
|
|
@ -172,13 +172,37 @@ hashes matching; interface-canon resolves 23 of 25 with seven hashes matching,
|
|||
the two exceptions being the known `Interface` and `Endpoint` pins. The check
|
||||
finds exactly what the T04 audit found by hand, which is the point.
|
||||
|
||||
### T04 — waiting on interface-canon
|
||||
### Result — 2026-09-20 (T04)
|
||||
|
||||
The two open pins are InterfaceCanon's to correct; its accepted boundary already
|
||||
treats Landscape `Interface` and Network attachment-point `Interface` as
|
||||
contextual mappings rather than exact aliases, so this is a citation fix, not a
|
||||
semantic dispute. Raised by State Hub message
|
||||
`13d355f2-554b-4a3a-a0ef-3f69eeafeae9` on 2026-09-20, unread and unanswered at
|
||||
the time of writing. The task is set to `wait` rather than done: the standing
|
||||
warning is the follow-up mechanism, and it will clear itself when the pin is
|
||||
corrected.
|
||||
Corrected in interface-canon at `20d7bfc2`, on the owner's instruction rather
|
||||
than by waiting for the unanswered message.
|
||||
|
||||
The cause was a third instance of one pattern. `Interface` and `Endpoint` were
|
||||
pinned twice, to ITC-LAND and to ITC-NET, because ITC-LAND section 13.2 lists
|
||||
them in a seed-concept block while the Network Model defines them. A list of
|
||||
names was read as a definition — the same mistake as CARING's Scope ladder
|
||||
(R-1), CARING's Environment values (F-3), and the Landscape seeds that hid
|
||||
`SoftwareSystem` and `SoftwareComponent` (T04 of INFO-WP-0027). The ITC-LAND
|
||||
pins are dropped, and Landscape section 13.2 now states in InfoTechCanon that
|
||||
`Interface`, `Endpoint` and `API` are pointers and that the Network Model owns
|
||||
the first two, so the next reader does not repeat it.
|
||||
|
||||
No disposition changes on either side; the mapping tables citing ITC-LAND
|
||||
section 13.2 as a related seed stand. The registered copy is refreshed to the
|
||||
corrected revision, both boundaries now resolve completely — security-canon 11
|
||||
of 11, interface-canon 23 of 23 — and `make check` carries no drift warnings.
|
||||
|
||||
## Closure — 2026-09-20
|
||||
|
||||
All four tasks are done. Any partner manifest can be checked by one command that
|
||||
verifies pinned hash and concept-name resolution together; accepted manifests are
|
||||
registered as provenance-preserving partner-owned copies and re-resolved on every
|
||||
`make check`, with drift reported as a warning naming the partner; the review kit
|
||||
requires both counts and says that one is never evidence of the other; and no
|
||||
resolution finding remains open against either accepted boundary.
|
||||
|
||||
The pattern worth naming, since it recurred four times in one day: a canon lists
|
||||
concept names in one artifact and defines them in another, and every consumer of
|
||||
the list treats the listing as ownership. Declarations and this check make that
|
||||
visible, but the underlying habit is a documentation one, and no check will stop
|
||||
it being written again.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue