glm-5.2
8d20f89902
Break the tty spec set (docs/architecture/crates/tty/) into atomic,
dependency-ordered tasks across two crates:
alknet-tty (lean core, depends on alknet-core only — ADR-057):
- crate-init, wire-codec, control-messages, negotiation, backend-trait,
adapter, review-tty
alknet-tty-local (sibling, portable_pty + libc — ADR-054):
- crate-init, pty-mode, pipe-mode, backend-impl, review-tty-local
integration:
- local-feature-reexport, integration-test, review-tty-final
Three review checkpoints at critical points: after the core crate (before
the local backend builds on the one-way-door TtyBackend trait — ADR-053),
after the local backend (validating REQ-TTY-01/02 and ADR-056), and a final
merge-readiness review. The high-risk tasks (backend-trait, adapter,
pty-mode) are flagged; the ADR-056 kill-on-Drop guard the POC lacked is
called out in both pty-mode and pipe-mode.
Validated with taskgraph: 115 tasks, no cycles, 10-generation parallel
structure with 3-way parallelism after crate-init and 2-way after the
backend trait.
106 lines
3.9 KiB
Markdown
106 lines
3.9 KiB
Markdown
---
|
|
id: tty/local-feature-reexport
|
|
name: Wire alknet-tty `local` feature gate and re-export LocalTtyBackend
|
|
status: pending
|
|
depends_on: [tty/review-tty, tty-local/review-tty-local]
|
|
scope: narrow
|
|
risk: low
|
|
impact: component
|
|
level: implementation
|
|
---
|
|
|
|
## Description
|
|
|
|
Wire the `local` feature gate on `alknet-tty` (declared in `tty/crate-init`)
|
|
to re-export `LocalTtyBackend` from `alknet-tty-local`. This is the seam
|
|
between the two crates (ADR-054): a consumer that wants the local backend
|
|
enables `features = ["local"]` and gets `alknet_tty::local::LocalTtyBackend`;
|
|
a consumer that only wants docker/ssh uses the default features and depends
|
|
on the backend crate directly — no `portable_pty` in the dependency tree.
|
|
|
|
### Cargo.toml (alknet-tty)
|
|
|
|
The `local` feature was declared in `tty/crate-init` but the
|
|
`alknet-tty-local` dependency was not yet wired. Add it as an optional
|
|
dependency activated by the `local` feature:
|
|
|
|
```toml
|
|
[features]
|
|
default = []
|
|
local = ["dep:alknet-tty-local"]
|
|
|
|
[dependencies]
|
|
alknet-tty-local = { path = "../alknet-tty-local", optional = true }
|
|
```
|
|
|
|
### Re-export module (alknet-tty/src/lib.rs)
|
|
|
|
Add a `local` module gated on the feature, re-exporting `LocalTtyBackend`:
|
|
|
|
```rust
|
|
#[cfg(feature = "local")]
|
|
pub mod local {
|
|
pub use alknet_tty_local::LocalTtyBackend;
|
|
}
|
|
```
|
|
|
|
A consumer with `features = ["local"]` accesses it as
|
|
`alknet_tty::local::LocalTtyBackend`.
|
|
|
|
### Verification
|
|
|
|
- `cargo check -p alknet-tty` (default features) — succeeds, no
|
|
`portable_pty` in the tree.
|
|
- `cargo check -p alknet-tty --features local` — succeeds,
|
|
`alknet_tty::local::LocalTtyBackend` is accessible.
|
|
- `cargo tree -p alknet-tty --features local` shows `portable_pty` pulled in
|
|
via `alknet-tty-local`; `cargo tree -p alknet-tty` (default) does NOT show
|
|
`portable_pty`.
|
|
- `cargo clippy -p alknet-tty --features local` succeeds with no warnings.
|
|
|
|
### Assembly-layer example
|
|
|
|
Document (in a doc comment or the crate root) the assembly pattern:
|
|
|
|
```rust
|
|
let mut backends = HashMap::new();
|
|
backends.insert("local".into(),
|
|
Arc::new(alknet_tty::local::LocalTtyBackend::new()) as Arc<dyn alknet_tty::TtyBackend>);
|
|
let tty_adapter = alknet_tty::adapter::TtyAdapter::new(backends);
|
|
```
|
|
|
|
This is the pattern the assembly layer (the CLI binary) uses to construct and
|
|
register the local backend. A docker-only deployment registers `docker`
|
|
instead; a mixed deployment registers both.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- [ ] `alknet-tty` Cargo.toml has `alknet-tty-local` as an optional dependency, `path = "../alknet-tty-local"`
|
|
- [ ] `local` feature activates `dep:alknet-tty-local`
|
|
- [ ] `alknet-tty/src/lib.rs` has `#[cfg(feature = "local")] pub mod local` re-exporting `LocalTtyBackend`
|
|
- [ ] `cargo check -p alknet-tty` (default features) succeeds
|
|
- [ ] `cargo check -p alknet-tty --features local` succeeds
|
|
- [ ] `cargo tree -p alknet-tty` (default) does NOT include `portable_pty`
|
|
- [ ] `cargo tree -p alknet-tty --features local` includes `portable_pty` via `alknet-tty-local`
|
|
- [ ] `cargo clippy -p alknet-tty --features local` succeeds with no warnings
|
|
- [ ] `cargo test -p alknet-tty --features local` succeeds
|
|
- [ ] Assembly-layer pattern documented (doc comment or crate root)
|
|
|
|
## References
|
|
|
|
- docs/architecture/crates/tty/overview.md — §"Feature Gates", §"Backend Location Map"
|
|
- docs/architecture/crates/tty/tty-backend.md — §"Backend registration and the assembly layer"
|
|
- docs/architecture/decisions/054-local-tty-backend-sibling-crate.md — ADR-054 (sibling crate behind `local` feature)
|
|
|
|
## Notes
|
|
|
|
> This is the seam between the two crates. The feature gate ensures a
|
|
> docker-only or ssh-only deployment doesn't pull in `portable_pty`. The
|
|
> `cargo tree` check is the verification: `portable_pty` appears only with
|
|
> `--features local`. This task depends on both review tasks
|
|
> (`tty/review-tty`, `tty-local/review-tty-local`) because it wires the two
|
|
> reviewed crates together.
|
|
|
|
## Summary
|
|
|
|
> To be filled on completion |