CLI: failproofai policies ignores NO_COLOR, and --no-color does not exist #688

failproofai policies prints ANSI colour even when NO_COLOR=1 is set, and there is no --no-color flag at all.

Most of the CLI already gets this right — install-prompt.ts, audit/report.ts and audit/cli.ts all honour it. src/hooks/manager.ts is the holdout, and it happens to be the output people most often pipe into CI logs.

Reproduce

Under a real TTY (piping hides it, because a non-TTY disables colour anyway):

script -qec "failproofai policies" /dev/null | grep -aoP '\x1B\[' | wc -l
# 32

script -qec "env NO_COLOR=1 failproofai policies" /dev/null | grep -aoP '\x1B\[' | wc -l
# 32   ← should be 0

The green ✓ marks come out as ESC[32m✓ESC[0m regardless.

Where to fix

src/hooks/manager.ts hardcodes ANSI escapes at 16 sites. Route them through paint() from src/hooks/tui.ts, which already gates on NO_COLOR through colorsEnabled().

src/hooks/install-prompt.ts:261 is a worked example of the pattern:

const { dim, bold, guide: teal, pink, pinkBold } = paint(!process.env.NO_COLOR);

Then add --no-color in bin/failproofai.mjs as an alias that sets NO_COLOR=1, and document it in the COMMANDS help block.

Please don't add a new colour module. tui.ts is the single source of truth for brand colour — a second one is what sank the earlier attempt in #256.

Done when

• NO_COLOR=1 failproofai policies emits zero ESC bytes under a TTY
• failproofai policies --no-color does the same
• a test covers it

Around 20 lines. Supersedes #251, which was closed while the bug was still live.

Happy to answer questions on the issue — first-time contributors very welcome.