standout

name	standout
description	Build, modify, review, or debug Rust CLI applications that use the Standout framework. Use for Standout handlers and state, app and command wiring, MiniJinja templates and CSS themes, output modes, testing with TestHarness, hooks, input chains, piping, partial adoption, or locating framework ownership.

Standout agent orientation

Treat Standout as the shell adapter around a CLI-free application library:

clap -> pre-dispatch -> handler -> post-dispatch -> render -> post-output -> output

Keep reusable application libraries completely free of CLI concerns. The binary package owns Clap, Standout, handlers, view DTOs, templates, styles, environment lookup, app construction, output formats, and final writes. Handlers are thin adapters: translate CLI input into library calls, then translate library results into serializable CLI view models.

Invariants

• Do not print, render, or emit ANSI from handlers. Return Output::Render(data), Output::Silent, or Output::Binary { ... }.
• Do not depend on Clap, Standout, CommandContext, Output, view DTOs, templates, styles, environment lookup, or app construction from a reusable library. Keep those in the CLI package.
• Keep durable dependencies in app state and request-scoped values in context extensions.
• Prefer structured output when an agent needs data, text output for stable rendered strings, and terminal-debug output for style-tag inspection.
• Test library behavior through its own interface first. Test adapters through typed handler calls; use TestHarness for the in-process argv-to-output pipeline; spawn a process only for seams the harness cannot model.
• Verify public signatures and integration tests in the checked-out version. Framework documentation can lag API changes.

Load the task branch

Read every reference whose condition matches the task; each is directly reachable here.

• Must read handlers-and-state.md before adding, changing, debugging, or unit-testing a handler, its arguments, Output, app state, or request extensions.
• Must read app-wiring.md before registering commands, using Dispatch, configuring templates/themes, running an app, or adding partial adoption/fallback behavior.
• Must read rendering-and-output.md before changing templates, CSS/themes, style tags, output modes, structured serialization, or output-file behavior.
• Must read testing.md before writing or reviewing Standout tests, choosing a test level, using TestHarness, or diagnosing test interference.
• Must read hooks-input-and-piping.md before adding hooks, declarative inputs, prompts, stdin/clipboard sources, or output pipes.
• Must read project-map-and-gotchas.md when locating ownership, choosing a crate/doc/example, upgrading copied code, or resolving an API mismatch.
• Must read implementation-quality-checklist.md before reviewing how completely or effectively an application leverages Standout.

Use crates/todo-example/todo-core/ as the canonical CLI-free library and crates/todo-example/tdoo/ as the canonical binary-only Standout CLI. For framework documentation work rather than application code, use the writing-standout-docs skill.