Close the last open import pins and the workplan (T04)
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
CI Smoke / container-smoke (push) Successful in 5s

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:
tegwick 2026-09-20 23:50:52 +02:00
parent 44bc71babc
commit 1527b33999
6 changed files with 77 additions and 20 deletions

View file

@ -87,4 +87,13 @@ different owner than the manifest pins, is reported as a
`federation_import_drift` warning naming this partner. It is a warning and not an
error because a stale partner pin is not this repository's file to fix.
Current result: **23 of 25 declared imports resolve** and all seven pinned hashes match. `Interface` and `Endpoint` remain pinned to ITC-LAND while the Network Model declares them; raised with interface-canon by State Hub message `13d355f2-554b-4a3a-a0ef-3f69eeafeae9` on 2026-09-20 and unanswered as of that date. The two warnings stand until that pin is corrected or qualified in place.
Current result: **23 of 23 declared imports resolve**, all seven pinned hashes
match, no drift.
The `Interface` and `Endpoint` pins were corrected in interface-canon at
`20d7bfc2` on 2026-09-20. Both names had been pinned twice, to ITC-LAND and to
ITC-NET; the ITC-LAND pins are dropped, since section 13.2 lists them as pointers
while the Network Model defines and owns them. Landscape section 13.2 now says so
in InfoTechCanon, so the next reader does not repeat it. The accepted
dispositions are unchanged: this was a citation fix, and the mapping tables that
cite ITC-LAND section 13.2 as a related seed stand as they are.

View file

@ -9,11 +9,10 @@
"path": "infospace/models/landscape/InfoTechCanonLandscapeModel.md",
"sha256": "4190b044fbd5e3eecf7b28e08608e99c7de3af5dd5f3a7554edee02423967fb1",
"concepts": [
"Interface",
"Endpoint",
"SoftwareSystem",
"SoftwareComponent"
]
],
"note": "Interface and Endpoint were pinned here and to itc-net. ITC-LAND section 13.2 lists them as pointers; the Network Model defines and owns them, so they are pinned to itc-net alone. Corrected 2026-09-20 after InfoTechCanon INFO-WP-0028 name resolution."
},
{
"model": "itc-ident",

View file

@ -17,6 +17,6 @@ manifests:
- partner: interface-canon
file: interface-canon.json
retrieved_from: infospace/models/interface/imports.json
partner_revision: 37fbe245bfd00fb1271af368eec7f0161247d57f
partner_revision: 20d7bfc2c3687fd15f00de10916d9ef976bf90ec
retrieved_at: "2026-09-20"
boundary: ../interface-canon-boundary.md

View file

@ -728,6 +728,14 @@ The Software and Solution domain represents logical and design-time software str
## 13.2 Seed Concepts
`Interface`, `Endpoint` and `API` appear below as pointers into the software and
solution domain, not as definitions. The
[Network Model](../network/InfoTechCanonNetworkModel.md) defines and owns
`Interface`, a network attachment point of a node, and `Endpoint`, an addressable
network surface; this model imports them. `SoftwareSystem` and
`SoftwareComponent` are defined here and declared in this artifact's
`owned_concepts`.
```text
SoftwareSystem
Application

View file

@ -17,7 +17,11 @@ from info_tech_canon.maintenance import (
source_evidence,
)
from info_tech_canon.contracts import coverage
from info_tech_canon.federation import import_manifest_review, registered_drift
from info_tech_canon.federation import (
import_manifest_review,
registered_drift,
registered_manifests,
)
from info_tech_canon.service import (
DEFAULT_INFOSPACE_ROOT,
concept_declaration_checks,
@ -233,8 +237,21 @@ def test_registered_drift_names_the_partner_not_the_canon():
assert {item["partner"] for item in warnings} <= {"interface-canon", "security-canon"}
def test_import_review_cli_exits_non_zero_on_a_finding(capsys):
manifest = DEFAULT_INFOSPACE_ROOT / "interfaces/manifests/interface-canon.json"
def test_import_review_cli_exits_non_zero_on_a_finding(tmp_path, capsys):
"""Built from a broken copy: a partner fixing its pins must not break this."""
source = json.loads(
(DEFAULT_INFOSPACE_ROOT / "interfaces/manifests/interface-canon.json").read_text())
source["imports"][0]["concepts"] = ["Interface"]
manifest = tmp_path / "imports.json"
manifest.write_text(json.dumps(source))
assert main(["import-review", str(manifest)]) == 1
payload = json.loads(capsys.readouterr().out)
assert [item["concept"] for item in payload["findings"]] == ["Interface", "Endpoint"]
assert [item["concept"] for item in payload["findings"]] == ["Interface"]
def test_registered_manifests_resolve_completely():
for item in registered_manifests(load_context()):
review = import_manifest_review(
load_context(), DEFAULT_INFOSPACE_ROOT / "interfaces/manifests" / item["file"])
assert review["ok"], (item["partner"], review["findings"])

View file

@ -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.