Skip to content

Keep TUI dependencies outside the default library install #983

Description

@flyingrobots

id: "GW20-027"
title: "Keep TUI dependencies outside the default library install"
type: "feature"
status: "planned"
milestone: "v20.1.0"
category: "required"
workstream: "tooling"
issue: "#983"
baseline_commit: "ceb58e656ec5bc85f0ae5991bf2a55599693bbb3"
feedback_sections: [18]
prerequisites: []

Feature

LLM prompt

Complete GW20-027: Keep TUI dependencies outside the default library install.
Read this entire task and its current GitHub issue before implementation.
Verify the current mainline and all prerequisite integrations.
Read AGENTS.md and the three TypeScript policy documents.
Use runtime-backed domain values and injected ports.
Keep parsing and codecs at the adapter boundary.
Preserve v20 APIs, stored identities, CRDT semantics, and failure meanings.
Use one coherent issue, PR, and mainline integration. Do not leave a broken intermediate state.
Problem to resolve:
A library-only consumer installs Bijou TUI packages and git-cas cockpit dependencies. It does not use those capabilities.
Acceptance checks:
A clean library-only install does not require the TUI dependency family.
The root Runtime and advanced imports work without TUI packages.
The supported CLI and TUI remain available through an explicit installation path with a clear missing-capability diagnostic.
Do not assume optionalDependencies reduce default installation. Prove the package graph.
Include transitive git-cas TUI and vault ownership in the dependency disposition.
Preserve compatible v20 exports and executable names. Record any upstream release requirement.
External gate: a compatible git-cas library dependency boundary that does not require its CLI, TUI, and unnecessary vault installation graph.
Record actual released package identities and compatibility before activation. No arbitrary git-cas version floor establishes readiness.
Read these source paths:
package.json
package-lock.json
scripts/package-payload/CheckPackagePayload.ts
bin/git-warp.ts
Prerequisites: None established. Recheck external readiness.
Scope exclusions: The entire v21 workspace split or an unreviewed breaking removal of CLI support.
Run all tests and benchmarks in COPY-based Docker without host repository mounts.
Use the project guarded runner and the shared git-locks authority.
Lock host/heavy-work and the exact worker key together for expensive work.
Limit build caches to 20 GiB, test data to 4 GiB, and logs to 128 MiB.
Require 50 GiB free on host and Docker backing storage before heavy work.
Enforce disk accounting, CPU, memory, timeout, and child-process shutdown.
Do not start an unguarded workload. Do not bypass a resource refusal.
Require full touched-code coverage for refactors and an all-green manual SSJS scorecard.
Record source, image, command, fixtures, results, limits, and the regression witness.
Commit only your own files. Do not amend, rebase, force, push, or publish without authorization.
Report incomplete or blocked checks. Do not claim completion from a narrow green test.
Link the issue, coherent PR, and actual mainline integration when those actions are authorized.

1. Background Context

Source: FEEDBACK-git-warp.md, sections 18.
The report SHA-256 is 9b15209d51cd705059a9e6bfebf0f6681ff832924c1462b99ff3cfebde6bacae.
The report uses npm git-warp 20.0.0 and git-cas 6.5.11.
Its runtime results come from macOS host experiments. This planning task did not rerun them.
Source review baseline: ceb58e65.

Tracker: #983.

Read these source and test surfaces before work:

2. Problem Description

A library-only consumer installs Bijou TUI packages and git-cas cockpit dependencies. It does not use those capabilities.

2b. Proposed Solution

Choose a compatible explicit CLI/TUI package or installation boundary. Make default library imports independent from it.

2c. Alternatives considered and rejected

Reject a private-import workaround. It does not provide a supported application contract.
Reject a documentation-only substitute when this task requires runtime behavior.
Keep larger storage and package redesigns under their existing issues.

2d. Acceptance Criteria

  • A clean library-only install does not require the TUI dependency family.
  • The root Runtime and advanced imports work without TUI packages.
  • The supported CLI and TUI remain available through an explicit installation path with a clear missing-capability diagnostic.
  • Do not assume optionalDependencies reduce default installation. Prove the package graph.
  • Include transitive git-cas TUI and vault ownership in the dependency disposition.
  • Preserve compatible v20 exports and executable names. Record any upstream release requirement.
  • External gate: a compatible git-cas library dependency boundary that does not require its CLI, TUI, and unnecessary vault installation graph.
  • Record actual released package identities and compatibility before activation. No arbitrary git-cas version floor establishes readiness.

2e. Test Plan

Golden: Compare clean default library and explicit CLI/TUI installs in Docker. Exercise root imports, CLI help, and the installed TUI entry boundary.

Edges: No optional packages; locked install; transitive TUI dependency; packed exports; Node and maintained Bun paths.

Known failure modes: preserve typed refusal, atomic publication, and complete evidence. Do not conceal unavailable support.

Fuzz and stress: use fixed fixture sizes and seeds. Apply the roadmap resource guards. Do not start an unbounded campaign.

3. Prerequisites

External gate: a compatible git-cas library installation boundary without transitive TUI obligations. Record exact package identities and proof.

None established as an internal issue dependency. Verify the current boundary and external readiness before activation.

4. Scope

In: A library-only consumer installs Bijou TUI packages and git-cas cockpit dependencies. It does not use those capabilities.

Out: The entire v21 workspace split or an unreviewed breaking removal of CLI support.

Safe intermediate state: one independently mergeable PR passes its relevant checks after its prerequisites.
Existing supported applications remain usable. Historical data remains intact.

5. Why now

This flaw blocks a supported Synapse store workflow or gives its operator incorrect guidance.
Resolve it within v20.1.0 without reducing the existing causal-history commitment.

6. Risks

Source inspection does not establish runtime or performance results.
Preserve historical identities, validation, and evidence. Do not weaken refusal to obtain a green result.
If the fix requires a breaking contract, record the conflict before activation. Do not hide it within a minor release.

7. Definition of Done

All acceptance checks have evidence from the exact candidate.
Relevant lint, typecheck, compatibility, and Docker checks pass.
The manual SSJS scorecard is green. Refactor coverage reaches 100% on touched code.
Record the issue, PR, and mainline integration commit. Record any external release gate.
A required check with missing evidence remains incomplete.

8. Stakeholders

James Ross: git-warp maintainer and acceptance owner.
Synapse store authors: applications need correct writes, reads, history, and operational guidance.
Library and CLI consumers: existing v20 contracts must remain usable.

9. Related Issues

Activity

  1. added this to the v20.1.0 milestone on Oct 7, 2026
  2. added
    type:featureNew capability or product behavior.
    priority:nextNext in line after active work.
    area:toolingPrimary work area: tooling.
    status:availableOpen and available for prioritization; not blocked or actively in progress.
    on Oct 7, 2026
  3. linear-code commented on Oct 7, 2026

    @linear-code
  4. added
    status:blockedBlocked by an explicit dependency or external condition.
    and removed
    status:availableOpen and available for prioritization; not blocked or actively in progress.
    on Oct 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:toolingPrimary work area: tooling.priority:nextNext in line after active work.status:blockedBlocked by an explicit dependency or external condition.type:featureNew capability or product behavior.

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions