00 - Executive Summary

Recommendation

Create tailrocks/termrock as an independent public Apache-2.0 Rust project for the shared TUI system. The project, repository, crate, and CLI naming family is:

Repository: tailrocks/termrock
Core crate: termrock
Lookbook:   termrock-lookbook
CLI:        termrock-lookbook

The project is deliberately built for Ratatui. The base component crate depends on ratatui-core, and every component works without features. Enabling crossterm adds event/backend/session convenience without replacing or changing those components; Tokio is not part of the shared crate, while the donor's executor-neutral update/view/subscription contracts and the drive_frame/drive_render frame drivers extract as one optional module. The public design does not introduce a renderer-neutral layer or accommodate competing TUI frameworks. The library targets modern truecolor terminals (Ghostty-class) with OSC 8/22/52 support and ships no capability-degradation paths.

The same repository owns a small Fumadocs site. Each public component has usage and interaction documentation plus browser-visible SVG states generated by the lookbook CLI. The CLI also owns the interactive terminal catalog and deterministic render/check workflow currently provided by tui-lookbook.

Extract code with path-level Git history, debrand it, break the jackin-core dependency, make the project consumable at an exact Git revision, and migrate jackin❯ before removing the in-tree donor. Prepare and scan inherited history in a dedicated clone; the first public main head is neutral, standalone, and buildable even though inherited donor snapshots may contain historical product vocabulary and may not build outside their former monorepo. Extraction is bug-compatible: known rendering defects are recorded at freeze and fixed only after parity, so jackin❯'s visual behavior never changes inside the ownership move. A crates.io preview is optional rather than an adoption prerequisite. jackin❯ is the only consumer migrated or validated by this roadmap. The extraction ships only the existing donor component set; new components and every other product adoption are explicit follow-up work after migration.

This project plays a role similar to a reusable component system: Tailrocks products share terminal interaction quality and visual vocabulary without recreating tabs, panels, dialogs, focus, scrolling, terminal restoration, and render testing. It is not a shared application kernel and does not own product state.

Why extract

The donor has enough value to justify independent ownership:

• roughly 17,000 lines of Rust across the component crate and lookbook;
• TEA-style pure update/effect/view conventions;
• tested terminal ownership and mode restoration;
• display-width-aware layout, input, focus, hover, scrolling, and output helpers;
• reusable panels, tabs, buttons, dialogs, lists, fields, hints, status, toasts, and diff views;
• an interactive lookbook plus deterministic SVG/render fixtures.
• an existing Fumadocs component catalog backed by those generated SVG previews.

Holla already implements terminal lifecycle, tabs, scrolling, task status, and output chrome directly with Ratatui/Crossterm. Velnor needs future runner/job visibility. Parallax remains web-first, but a future interactive CLI should not rebuild these mechanics. This is evidence that a neutral component library has future value, not execution scope: their repositories are not checked out, changed, or validated by this roadmap.

Required cleanup

The donor is not publishable unchanged:

• jackin-tui is publish = false and depends on jackin-core;
• ANSI, scrolling, dialog, and bottom-chrome helpers are split or duplicated across layers;
• palette constants mix semantic state, Tailrocks style, and jackin❯ product meaning;
• brand header, container/agent helpers, modal geometry, and animations contain product vocabulary;
• lookbook machinery is neutral, but many stories contain roles, workspaces, agents, containers, and product paths;
• the current preview CLI, generated assets, and component catalog are owned by the jackin❯ repository rather than by the components they document;
• Tokio is currently a direct dependency even for consumers that may need widgets only.

Ownership rule

The shared project owns terminal mechanics and component contracts. Consumers own product meaning and effects.

Shared:

• semantic theme tokens and the default phosphor preset;
• the scoped terminal session (optional crossterm feature), text geometry, input, focus, hover, scrolling, layout;
• neutral components and the executor-neutral base runtime module, optional by use (update/view/subscription contracts and the frame driver);
• typed OSC hyperlink/pointer/clipboard requests with pure encoders;
• lookbook registry/harness, deterministic rendering, and conformance utilities.
• the interactive preview CLI, generated neutral SVG catalog, Fumadocs component documentation, and neutral interaction conventions.

Consumer-local:

• brand composition and product wording;
• agent/container/job/trace/database/credential state;
• terminal-ownership process globals and title policy;
• filesystem, process, network, secret, persistence, and telemetry effects;
• application layouts and stories using domain fixtures.

Sequence

1. authorize repository creation and freeze the closed decision record as the implementation contract;
2. freeze donor behavior with inventory, the recorded quality backlog, and CI-verified fixtures;
3. prepare and audit filtered history locally, without publishing a raw donor tip;
4. remove product coupling, introduce semantic theme/brand inputs, and publish the first neutral buildable main head;
5. establish the neutral lookbook, terminal conformance, and standalone Fumadocs catalog;
6. publish an immutable Git revision that consumers can pin, with crates.io publication optional;
7. migrate jackin❯ without redesign and delete local donor code/docs only after parity passes;
8. land the recorded post-parity quality fixes, publish the first tag/API baseline, enable TermRock branch protection, and close the roadmap only after the complete jackin❯ migration is green;
9. adopt from other products later through separately scoped work using exact Git revisions or semver releases.

The detailed sequence is in 04 - Extraction and migration plan. The target contracts and operating gates are specified in 06 - Public API and refactoring, 07 - Repository engineering, and 08 - Migration evidence and gates.