Creatidy/scarcity-router
5
0
Fork 0
Code Issues 13 Pull requests Projects Releases Packages Wiki Activity Actions

I. Integrated acceptance + coherent install/first-run + program closeout #141

New issue
Open
opened 2026-09-26 21:44:36 +00:00 by kilo · 2 comments
kilo commented 2026-09-26 21:44:36 +00:00
Member
Copy link

Child I of #132 (final). Review the complete self-hosted path as ONE product and close the program coherently.

install server → configure TLS → start server service/container
  → install worker → pair once → authenticate Codex source once
  → install worker service → discover models → expose logical models
  → issue client API key → configure OpenAI-compatible client → execute

Scope

  1. Walk the full path against the real repository; identify steps still requiring repository knowledge or hand-written commands; remove unnecessary friction (minimal professional open-source UX — no wizard for its own sake).
  2. Integrated acceptance rehearsal of the representative target (#132) against composed fixtures: bare gpt-5.6-luna + max + tools + 128k request through the public boundary; client tool round trip (to the level child E evidenced); exact-pin acceptance still green; restricted Daybreak never selected; audit shows selected == executed.
  3. Concise documentation updates across architecture, execution-surface, worker-protocol, security, release/install and acceptance docs — update in place, no repetition of code or prompt text, no new large design document.
  4. Program closeout report for the owner: issues, PRs, exact heads reviewed, gate results, external contract changes, remaining unsupported behavior, security-review state, remaining owner-side live acceptance steps.

Tests

End-to-end composed fixtures covering the walked path; docs-links/integrity checks where the repo has them.

Complexity boundary

Docs + friction fixes + composed tests only; any substantive product change discovered here gets its own issue rather than scope-creep. Budget: 120 min wall clock. Depends on all other children.

Acceptance

Full gate green; program report delivered; PR open for human review; not merged; REPRESENTATIVE_CLIENT_READY_FOR_OWNER_ACCEPTANCE or an explicit blocker list ending the report.

Child I of #132 (final). Review the complete self-hosted path as ONE product and close the program coherently. ``` install server → configure TLS → start server service/container → install worker → pair once → authenticate Codex source once → install worker service → discover models → expose logical models → issue client API key → configure OpenAI-compatible client → execute ``` ## Scope 1. Walk the full path against the real repository; identify steps still requiring repository knowledge or hand-written commands; remove unnecessary friction (minimal professional open-source UX — no wizard for its own sake). 2. Integrated acceptance rehearsal of the representative target (#132) against composed fixtures: bare `gpt-5.6-luna` + `max` + tools + 128k request through the public boundary; client tool round trip (to the level child E evidenced); exact-pin acceptance still green; restricted Daybreak never selected; audit shows selected == executed. 3. Concise documentation updates across architecture, execution-surface, worker-protocol, security, release/install and acceptance docs — update in place, no repetition of code or prompt text, no new large design document. 4. Program closeout report for the owner: issues, PRs, exact heads reviewed, gate results, external contract changes, remaining unsupported behavior, security-review state, remaining owner-side live acceptance steps. ## Tests End-to-end composed fixtures covering the walked path; docs-links/integrity checks where the repo has them. ## Complexity boundary Docs + friction fixes + composed tests only; any substantive product change discovered here gets its own issue rather than scope-creep. Budget: 120 min wall clock. Depends on all other children. ## Acceptance Full gate green; program report delivered; PR open for human review; not merged; `REPRESENTATIVE_CLIENT_READY_FOR_OWNER_ACCEPTANCE` or an explicit blocker list ending the report.
kilo commented 2026-09-27 21:01:49 +00:00
Author
Member
Copy link

Additive scope note (D-056, PR #147 — frozen scope text above unchanged):

D-056 pt 10 changes the acceptance shape of this child's rehearsal and closeout report — evidence is layered, and "ZCode works" alone is no longer the end-state claim:

  • Tier 1 — generic protocol-level acceptance: deterministic OpenAI-compatible fixtures (the #133 family) and SDK-level smoke where practical.
  • Tier 2 — representative coding harness: the ZCode-shaped rehearsal in scope item 2 above, unchanged as the Tier-2 exercise.
  • Tier 3 — broader harness evidence: Kilo / Cline as practical in the available environment.
  • No compatibility claim without evidence: a harness that cannot practically be exercised is recorded NOT LIVE VERIFIED, never assumed compatible from protocol similarity. Adding a harness validates the common semantic contract — never a router-specific client adapter.
  • The closeout report states the tiered evidence explicitly, and final verification includes that the delivered product contains no client-identity branching (if zcode/if kilo/if cline) in the routing core. The REPRESENTATIVE_CLIENT_READY_FOR_OWNER_ACCEPTANCE marker above remains the Tier-2 statement inside that layered report; its tool-round-trip clause means "to the level child E evidenced" — a TOOL_BRIDGE_NO in #137 is an honest reported state, not a program failure.

Authoritative text: D-056 pt 10 in docs/decisions.md; "Representative-harness acceptance" in docs/architecture.md.

Additive scope note (D-056, PR #147 — frozen scope text above unchanged): D-056 pt 10 changes the acceptance shape of this child's rehearsal and closeout report — evidence is layered, and "ZCode works" alone is no longer the end-state claim: - **Tier 1 — generic protocol-level acceptance:** deterministic OpenAI-compatible fixtures (the #133 family) and SDK-level smoke where practical. - **Tier 2 — representative coding harness:** the ZCode-shaped rehearsal in scope item 2 above, unchanged as the Tier-2 exercise. - **Tier 3 — broader harness evidence:** Kilo / Cline as practical in the available environment. - No compatibility claim without evidence: a harness that cannot practically be exercised is recorded **NOT LIVE VERIFIED**, never assumed compatible from protocol similarity. Adding a harness validates the common semantic contract — never a router-specific client adapter. - The closeout report states the tiered evidence explicitly, and final verification includes that the delivered product contains no client-identity branching (`if zcode`/`if kilo`/`if cline`) in the routing core. The `REPRESENTATIVE_CLIENT_READY_FOR_OWNER_ACCEPTANCE` marker above remains the Tier-2 statement inside that layered report; its tool-round-trip clause means "to the level child E evidenced" — a TOOL_BRIDGE_NO in #137 is an honest reported state, not a program failure. Authoritative text: D-056 pt 10 in `docs/decisions.md`; "Representative-harness acceptance" in `docs/architecture.md`.
kilo commented 2026-10-27 21:24:40 +00:00
Author
Member
Copy link

2026-10-27 owner backlog disposition (D-083, governance issue #228). This issue remains open with its wontfix label unchanged; history preserved. Its outstanding Tier-2/Tier-3 harness and installed integration acceptance content is re-homed to active successor #227, which correctly models composed acceptance as a downstream stage following the required component implementations and artifacts (native dependencies #227 → #183/#186; the former inverted #186 → #141 edge was removed). Retained: D-056 pt 10 layered evidence, no compatibility claim without evidence, NOT LIVE VERIFIED honesty, live/owner acceptance gates stay separately authorized. See D-083 in docs/decisions.md.

**2026-10-27 owner backlog disposition (D-083, governance issue #228).** This issue remains open with its `wontfix` label unchanged; history preserved. Its outstanding Tier-2/Tier-3 harness and installed integration acceptance content is re-homed to active successor **#227**, which correctly models composed acceptance as a downstream stage following the required component implementations and artifacts (native dependencies #227 → #183/#186; the former inverted #186 → #141 edge was removed). Retained: D-056 pt 10 layered evidence, no compatibility claim without evidence, `NOT LIVE VERIFIED` honesty, live/owner acceptance gates stay separately authorized. See D-083 in `docs/decisions.md`.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
develop
issue-246-authorized-receipt
issue-245-mi-startup
issue-226-administrator-ux
issue-183-observer-access
issue-183-event-acceptance
issue-183-internal-events
issue-183-resource-state
issue-242-secure-bootstrap
issue-238-mi-server
issue-239-architecture-reconciliation
issue-224-certificate-lifecycle
issue-224-origin-bound-worker
issue-224-worker-ca-trust
issue-234-evidenced-resources
issue-186-installed-lifecycle
issue-186-ghcr-distribution
issue-225-cancel-paths
issue-228-backlog-disposition
issue-222-active-mi
issue-176-mi-consumer
issue-185-contract-conformance
issue-219-project-security-audit
issue-181-responses-subset
issue-214-claude-subscription
issue-205-review-result-recovery
issue-174-executable-contract
issue-215-conversational-review
issue-210-d069-review-governance
issue-212-d069a-bootstrap
issue-202-dependency-eligibility
issue-184-strict-no-payg
issue-175-kernel-requirements
issue-180-native-authority-boundary
issue-182-readable-status
issue-195-post-selection-gates
issue-179-catalog-effort
issue-178-exact-target-pin
issue-190-workflow-self-remediation
task/168-capacity-controlled-home
fix/143-scenario11-cancel-race
policy/zai-model-governance-campaign
main
No results found.
Labels
Clear labels   
accessibility
Barrier affecting people with disabilities

  
bug
Something isn't working

  
documentation
Improvements or additions to documentation

  
duplicate
This issue or pull request already exists

  
enhancement
New feature or request

  
good first issue
Good for newcomers

  
help wanted
Extra attention is needed

  
invalid
This doesn't seem right

  
P1
Owner-declared highest explicit implementation priority (loop ordering rank)

  
P2
Required product and integration work

  
P3
Deferred or producer-dependent work

  
question
Further information is requested

  
wontfix
This will not be worked on

No labels
accessibility
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
P1
P2
P3
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Creatidy/scarcity-router#141
No description provided.