mirror of
https://github.com/tiennm99/ccs.git
synced 2026-10-12 18:15:48 +00:00
The previous commit assumed Claude Code's fable resolver strips [1m] and therefore never wrote the suffix into ANTHROPIC_DEFAULT_FABLE_MODEL. That premise only holds when ANTHROPIC_BASE_URL is unset or points at api.anthropic.com. Behind a proxy (CLIProxy, headroom, ...) Claude Code 2.1.259 does the opposite: - the fable alias resolver passes the env value through untouched, so a saved `claude-fable-5-1[1m]` reaches the model picker as-is; - the context-window resolver grants 1M unconditionally when the model id carries [1m], and otherwise trusts a natively-1M model only when the base URL is first-party. Bare `claude-fable-5-1` via 127.0.0.1 is clamped to 200k even though CLIProxy's /v1/models advertises max_input_tokens 1M. So the suffix is the only thing that turns the long window on for CCS, and stripping it from the Fable key is what kept `ccs claude --model fable` at 200k. A headroom settings profile with the suffix saved on that key showed the 1M window in the same Claude Code build, which is how the inversion was caught. Changes: - Drop the suffix-stripping key guard; ANTHROPIC_DEFAULT_FABLE_MODEL now receives and keeps [1m] exactly like the opus/sonnet tiers. - On a long-context launch (explicit --1m, or a saved [1m] on any Anthropic tier key) fill a missing Fable tier with the catalog Fable model plus [1m]. The model-neutral claude profile pins no Fable model, so `--model fable` used to fall back to Claude Code's bare default and lose the window even when every other tier asked for 1M. An explicit mapping always wins, --no-1m never fills, and providers without a catalog Fable model are left alone. - Add getDefaultFableTierModel() to the model catalog for that default. Verified with a stub Claude binary that dumps its environment: ccs claude --model fable -> ANTHROPIC_DEFAULT_FABLE_MODEL=claude-fable-5-1[1m] ccs claude --1m -> ANTHROPIC_DEFAULT_FABLE_MODEL=claude-fable-5-1[1m] ccs claude --no-1m --model fable -> no Fable tier written, ANTHROPIC_MODEL stripped
CCS Test Suite
Root TypeScript and JavaScript tests run with Bun's test runner. Native shell, PowerShell, Docker, and standalone probes cover contracts that need a real platform or process boundary.
Ownership
| Area | Path | Use for |
|---|---|---|
| Unit | unit/ |
Focused module and command behavior |
| Integration | integration/ |
Cross-module, process, proxy, auth, and web-server behavior |
| End to end | e2e/ |
Packaged CLI workflows |
| npm package | npm/ |
Installation, exports, and package behavior |
| Native | native/ |
Unix and Windows shell behavior |
| Docker | docker/ |
Compose and stable network/service contracts |
| Documentation | docs/ |
Repository documentation invariants |
| Shared support | shared/ |
Fixtures and helpers reused by suites |
| Mocks | mocks/ |
Bounded test doubles and fixtures |
Some source domains also keep focused tests in src/**/__tests__/. Follow the
nearest established pattern and avoid moving tests solely for taxonomy.
Commands
Commands are defined in ../package.json. Bucket membership
and execution live in
../scripts/run-test-bucket.js.
bun run test:fast # Fast Bun test bucket
bun run test:slow # Slow Bun test bucket
bun run test:all # All root non-e2e Bun test buckets
bun run test:unit # tests/unit
bun run test:npm # tests/npm
bun run test:native # Native Unix edge-case script
bun run test:e2e # tests/e2e with fail-fast and extended timeout
bun run test # Build, then test:all
For the normal contributor gate:
bun run format
bun run lint:fix
bun run validate
For the closest local equivalent to PR CI:
bun run validate:ci-parity
Dashboard tests use Vitest and are documented in
../ui/README.md.
Test Isolation
- Set
CCS_HOMEto a temporary directory. - Never read or modify a contributor's real
~/.ccs/or~/.claude/. - Use
getCcsDir()from../src/utils/config-manager.tsfor CCS paths. - Keep fixtures deterministic and free of credentials or private account data.
- Use real behavior at the boundary under test; do not weaken assertions to hide regressions.
Adding Coverage
- Add a focused unit test for isolated logic.
- Add integration coverage when behavior crosses modules, processes, HTTP, or persistence boundaries.
- Add e2e coverage when command routing or packaged CLI behavior is the contract.
- Add native or Docker coverage only when platform/runtime behavior cannot be represented faithfully in Bun tests.
- Run the smallest relevant command first, then broaden to the contributor or CI-parity gate when shared contracts changed.