Establish first secure SR–MI installed integration #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Implement the smallest verifiable Foundry installation integrating the canonical Scarcity Router consumer with Model Intelligence's existing evidence publication contract. Inspect and pin exact upstream revisions, retain standalone component operation and component-owned state, use the single canonical Compose without inventing an MI daemon, and preserve authenticated TLS boundaries. Validate configuration, installation, startup, authenticated SR access and actual evidence consumption, distinguishing synthetic tests from live-provider acceptance. Document prerequisites and blockers, including Kernel native-host compatibility and Console scaffold status. Report confirmed upstream defects in their owning repositories.
Initial canonical source inspection (2026-10-31): SR
209f7d39f3ecebbd1b98b11d7c44c63192fe50a4, MIe8a6b81546994438038d22fd08fc041c6901d9cd. SR's optional MI dependency points tod65891668b7e79f7b666c021f02a1b4bf8c4ca9c. The inspected SRcontrol_server.pyhas no MI consumer configuration and its Dockerfile does not install the MI extra; an explicit-input library acceptance is not proof of composed-server integration. MI's historical installed receipt used older commits and synthetic evidence, and reports that the selected Z.ai source did not establish positive adoption. Artifact hashes do not authenticate publishers. Do not claim authenticated integrated operation until the upstream server composition, independent reference custody, exact binding, and target-host TLS and authorization are validated.The source-owned composed-server integration gap is tracked as scarcity-router #238. This is a missing opt-in capability, not a defect in the earlier explicitly library-only delivery.
Current-source experiment: built and installed MI
e8a6b81546994438038d22fd08fc041c6901d9cdand SR209f7d39f3ecebbd1b98b11d7c44c63192fe50a4from exact archives in an isolated environment. 17 maintained SR consumer tests passed with synthetic fixtures. Installed MI's live refresh retrieved all eight public sources and published cut SHA-256f3492dad36ed8003344927df530395bc219c7fa5b451e269047413ad43a5feaf; installed SR loaded that cut and verified a decision utilization receipt using synthetic selection inputs. The label wasSynthetic model [MI unsupported]: the source lacks exact channel/configuration/effort bindings and this is not positive adoption. SR's declared MI pin is different; the current MI wheel was explicitly installed with--no-deps, not resolved as the declared extra. The adapted historical installed harness failed its old default-catalog bootstrap assertion against the current SR runtime. No server startup, authenticated access, live inference, target-host TLS or deployed integration has been established. Experiment artifacts and logs:/tmp/kilo/foundry-mi-explicit-stage4/on the test host.Independent GLM-5.3 review of the initial local documentation changes found no factual errors, misleading completion claims, or security regressions. It identified a concrete Compose image compatibility caveat:
--tls-reload-hostnameis supported at inspected SR209f7d39f3ecebbd1b98b11d7c44c63192fe50a4but absent from its parent. The local README and example environment now call out the flag, and the README notes that no SR release was published at inspection. These follow-up edits have not themselves been independently reviewed. Compose example rendering andgit diff --checkpass; this does not change the integration acceptance status.2026-10-31 revalidation: SR
developremains209f7d39f3ecebbd1b98b11d7c44c63192fe50a4, MIdevelopremainse8a6b81546994438038d22fd08fc041c6901d9cd; SR #238 remains open and unassigned, with no open SR PR. A separate read-only assessment confirms that installing the optional dependency or mounting a cut cannot supply the missing authenticated-server consumer wiring. Foundry-owned packaging can exercise the library seam but cannot honestly claim the requested server integration without replacing or modifying upstream server logic. Positive adoption additionally requires source-owner-reviewed evidence and exact associations rather than inferred channel/configuration/effort/freshness. The separately scoped documentation correction is PR #2; it does not resolve this issue.2026-11-01: Reopened because the original installed-integration acceptance was not completed by PR #2. Canonical SR
f96d58e6d7d0fffdbe70476850d824efa5de2fb5has the composed--mi-configpath and pins MId65891668b7e79f7b666c021f02a1b4bf8c4ca9c; MIdevelopise8a6b81546994438038d22fd08fc041c6901d9cd.An isolated Docker experiment using an MI-enabled source-built image exercised verified TLS, protected first-admin bootstrap, authenticated
/v1/select, retained MI utilization verified against SR's internal routed decision, and invalid reload preserving the prior cut. This uses synthetic evidence, not positive live-provider applicability. The exact relationship between that internal receipt and the authorization-filtered public HTTP decision still needs a documented verification contract. Startup ordering risk reproduced and reported upstream as SR #245. Foundry packaging and fresh independent review remain in progress; neither M0 nor M1 is accepted.2026-11-01: PR #8 merged as experimental opt-in integration at Foundry main
83a5b630576e7652a33b5811c1271a2119839498. Exact PR HEAD passed 34/34 combined tests including Docker. Independent review evidence and image provenance are recorded on PR #8.In a separate actual TLS/onboarding run at PR HEAD with synthetic MI and two registered resources, both authorization profiles returned no_solution: configured-resource catalog
reasoning_effortremained null and resources were also unobserved. The blocked resource was redacted in this no-solution HTTP response. Retained MI utilization verified the internal routed decision and exact cut; it did not directly verify against the authorization-filtered public response. Five invalid/mismatched/untrusted reloads returned 400 and preserved the prior cut. Installed pinned consumer/server tests passed 17/17 and 9/9, respectively; these do not prove a viable authorized filtered choice. See SR #246 for public/retained evidence verification and SR #245 for startup transaction behavior. M0/M1 remain unaccepted.PR #9 merged test-only MI input guard regressions at
5b3be4c1054e2966ca2916831de64b2097dd5ce4. Forgejo closed this issue on merge despite the PR being partial; reopened because viable-resource integration and M1 acceptance remain unverified. SR #245 and #246 remain open.