Carry secret-backed env vars from old CI into pyproject (lossless migration)

[thorwhalen]

Answers a gap you flagged before the fleet migration: migration should read the current CI and carry its secret wiring into pyproject.toml, rather than relying on the agent (skill) to do it by hand.

What it does

ci-to-uv, ci-to-stub, and the batch fleet-stub now extract ${{ secrets.X }} references from the existing workflow's env: blocks and inject any not-yet-declared ones into [tool.wads.ci.env].extra_envvars — recording a secret_aliases entry when the env-var name differs from the secret name (e.g. HF_TOKEN ← HF_WRITE_TOKEN). Migration is now lossless: secrets wired only in the old YAML are preserved instead of silently dropped.

This is in the migration code, not just the skill — so it's deterministic and works identically whether driven by you, an agent, or the batch loop over your 10–20 repos.

Precision (avoids re-introducing over-assignment)

Only env: blocks are scanned — not the reusable-workflow secrets: pass-through (transport ≠ usage) and not with: action inputs. Infra secrets (PYPI_PASSWORD, GITHUB_TOKEN, TEST_PYPI_PASSWORD) are excluded. Carried vars go to extra_envvars (available-if-set, never fails a build); you promote to required/test if a test truly depends on one. The command prints exactly what it carried.

Batch behavior

fleet-stub stages pyproject.toml alongside ci.yml and notes the carry in the per-repo commit message; a repo is noop only when neither the workflow nor the env changed.

End-to-end check

For an inline-uv ci.yml with OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} and HF_TOKEN: ${{ secrets.HF_WRITE_TOKEN }} (not yet in pyproject), ci-to-stub produced:

extra_envvars = ["OPENAI_API_KEY", "HF_TOKEN"]
[tool.wads.ci.env.secret_aliases]
HF_TOKEN = "HF_WRITE_TOKEN"

and a stub passing PYPI_PASSWORD, OPENAI_API_KEY, HF_WRITE_TOKEN.

Skill (wads-migrate) updated to document the auto-carry. Tests added. Full suite: 292 passed.