fix(cli): use named Space colors in generated README frontmatter

[sergiopaniego]

Summary

openenv push generated Space frontmatter with hex colours, but Hugging Face Spaces only
accepts named colours for colorFrom and colorTo. The upload failed before any file was
written:

✗ Upload failed: Invalid metadata in README.md.
- "colorFrom" must be one of
- "colorTo" must be one of

This blocked pushing any environment whose README had no frontmatter of its own.
init.py already picks from the valid set, so push.py now agrees with it.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• New environment
• Refactoring

Alignment Checklist

• I have read .claude/docs/PRINCIPLES.md and this PR aligns with our principles
• I have checked .claude/docs/INVARIANTS.md and no invariants are violated
• I have run lint and tests and addressed all issues

RFC Status

• Not required (bug fix, docs, minor refactoring)

Test Plan

Reproduce on main by pushing any env whose README has no frontmatter, for example a
freshly written one, and the upload fails with the error above. With this branch the same
push succeeds.

Verified end to end: envs/pelican_svg_env pushed to
a live Space, which built
and reached RUNNING with /health returning 200.

The valid set is red, yellow, green, blue, indigo, purple, pink, gray, and
_generate_hf_config() in init.py:205 already uses exactly that list, so the two
codepaths now produce metadata the Hub accepts.

Claude Code Review

N/A

---

Note

Low Risk
Single-string default in CLI staging logic with no auth, data, or runtime behavior changes.

Overview
Fixes openenv push failing when it injects Hugging Face Space frontmatter into a README that has none: colorFrom / colorTo are now named colours (blue, indigo) instead of hex values, which the Hub rejects.

Only affects the default frontmatter block in _prepare_staging_directory; behaviour matches init.py’s valid colour set so uploads pass metadata validation.

^{Reviewed by Cursor Bugbot for commit 6e6c296. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[bot-ci-comment]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[cursor]

Alignment Review Report

Automated Checks

• Lint: PASS — ruff format --check, ruff check, and usort check all pass on the changed file src/openenv/cli/commands/push.py. (The full-tree lint.sh hook still exits non-zero due to ~20 pre-existing unrelated envs/** reformat candidates — none touched by this PR.)
• Debug code: CLEAN — No print()/breakpoints introduced. check-debug.sh only surfaces pre-existing console.print(...) user-facing CLI output, none of it on the two changed lines.

Open RFCs Context

Open/active RFCs (000/001/002/003/005 In Review, 004 no-status, 010 Draft) all concern the environment & agent runtime spec (Gym/MCP API, rewards, harnesses, world-modeling). None cover the openenv push CLI's Hugging Face Space README frontmatter generation. RFC 002 (env-spec) is the nominal "env/deployment spec" area but prescribes nothing about Space thumbnail colors → no conflict.

Tier 1: Fixes Required

None.

The change is correct. HF's Spaces config reference restricts colorFrom/colorTo to the named set red, yellow, green, blue, indigo, purple, pink, gray. The prior hex values ('#00C9FF', '#1B2845') were rejected by Hub metadata validation; blue/indigo are valid, are valid unquoted YAML scalars, and match the named-color list openenv init already uses (init.py _generate_hf_config, line 204) — so the two frontmatter generators are now consistent.

Tier 2: Alignment Discussion

Principle Conflicts

None identified. If anything this is mildly positive alignment: "Be hands-on / production-ready from day one" (generated config now passes Hub validation) and "one canonical way" (the hardcoded push fallback now matches init.py's color list). No invariant is touched (no reset/step/state, generics, Pydantic wire types, rewards, client-server, MCP/WebSocket, agent isolation, credentials, or container isolation).

RFC Conflicts

None identified.

Notes (non-blocking)

• Root cause corroborated: scripts/prepare_hf_deployment.sh:672-678 already force-rewrites colorFrom: blue / colorTo: green at deploy time "to pass Hub validation regardless of source README defaults" — a workaround for exactly this bug. Both that sanitizer and the original hex frontmatter block were authored by @burtenshaw, so this PR fixes the root cause upstream (and could eventually let that sed workaround be retired).
• Optional follow-up (out of scope): two committed READMEs still carry hex colors emitted by the old code — envs/atari_env/README.md (#FF6200/#D4151B) and envs/chat_env/README.md (#0084FF/#25D366). They're masked at deploy by the sanitizer above, but note openenv push only adds base_path to pre-existing frontmatter (it does not rewrite an existing colorFrom/colorTo), so a direct openenv push of those two envs would still emit invalid hex. Normalizing them to named colors would fully close the gap.

Summary

• 0 mechanical issues to fix
• 0 alignment points for human review (1 positive-alignment note, 1 optional out-of-scope cleanup)
• 0 RFC conflicts to discuss

Suggested reviewer: @burtenshaw (author of both the original frontmatter block and the deploy-time color sanitizer).

  

_{Sent by Cursor Automation: Pre-review}

[cursor]

Correct fix. HF's Spaces config reference only accepts named colors (red, yellow, green, blue, indigo, purple, pink, gray); the previous hex values were rejected by Hub metadata validation. blue/indigo are valid and also match the named-color list openenv init already uses (init.py:204), so both frontmatter generators are now consistent. Verified: ruff/usort pass and this is valid YAML.