Model-routing guidance across the rules, skills, and harness-steering docs
still recommends Sonnet 4.6 / Opus 4.5-4.6 by name. Readers on the current
generation have to map those onto Sonnet 5 / Opus 5 themselves, and the
recommendation reads as pinned to a superseded generation.
Renames the recommended models in guidance tables and updates two pinned
model IDs in code samples:
- rules/steering guidance: .cursor, .kiro, and the seven translated
performance.md copies (ja-JP, zh-CN, zh-TW, ko-KR, pt-BR, es, tr)
- skills/prompt-optimizer complexity-routing table (+ zh-CN copy)
- skills/cost-aware-llm-pipeline MODEL_SONNET constant (+ zh-CN, ja-JP)
- docs/examples project-guidelines template, which pinned the invalid ID
claude-sonnet-4-5-20250514 (+ zh-TW, ja-JP copies)
Deliberately left alone:
- The "Pricing Reference (2025-2026)" table in cost-aware-llm-pipeline.
Renaming those rows while keeping the existing per-token figures would
assert Claude 5 pricing this change has not verified.
- Executable model config (.opencode/opencode.json, agent.yaml). Those pins
change real agent behavior and belong in their own reviewed change.
- Historical and illustrative references: the-shortform-guide session
transcripts, the ECC-PRO roadmap log entry, gan-style-harness's
"Opus 4.5-class"/"Opus 4.6-class" capability tiers, and
strategic-compact's deliberately generic "400k Opus 4.x" example.
- docs/ATLAS-CLOUD-GUIDE.md, which lists a third-party provider's catalog.
Documentation wording only; no behavioral change.
Co-authored-by: Phumchai Tanonsi <274848436+phumchai1515-prog@users.noreply.github.com>
* fix: make the installer runtime pass strict supply-chain vetting
Remediate the four enterprise supply-chain vetting blockers from
affaan-m/ECC#2502 so the installer runtime (package.json + manifests +
scripts/lib/**) passes strict exact-pin evidence policy:
1. Remove the package.json `postinstall` lifecycle script (it only echoed a
post-install banner) and move that banner to an explicit opt-in
`npm run welcome` command. No install-time lifecycle script remains.
2. Exact-pin every dependency in package.json (dependencies + devDependencies)
to the versions already resolved in package-lock.json; no ^/~ ranges.
3. Replace non-ASCII characters on the installer runtime script/config surface:
em-dashes (U+2014) in scripts/lib/{path-safety,install-executor,
install/link-rewrite}.js comments and the two "Itô" (U+00F4) occurrences in
manifests/{install-components,install-modules}.json descriptions become
ASCII, so strict-surface Unicode scanners are clean.
4. Drop the bare `require("ajv")` from scripts/lib/install-state.js; the file
already carries a complete hand-rolled validator enforcing the same
schemas/install-state.schema.json (ecc.install.v1) constraints, so the
installer closure is dependency-free (zero non-builtin bare requires).
Refs affaan-m/ECC#2502
* fix: avoid unpinned welcome invocations
Signed-off-by: Samar Tomar <samar_tomar@hotmail.com>
* fix: validate translated skill frontmatter
Signed-off-by: Samar Tomar <samar_tomar@hotmail.com>
* fix: repair skill frontmatter YAML
Signed-off-by: Samar Tomar <samar_tomar@hotmail.com>
* fix: add MIT license to core skill manifests; pin verification-loop tsc invocation
* fix: preserve tsc/pyright exit status in verification-loop type-check (set -o pipefail)
* chore(deps): sync lockfiles with exact-pinned package.json
Regenerate package-lock.json and yarn.lock so the pinned dependency
specs are reflected in both lockfiles. npm ci and Yarn's --immutable
install now pass the sync check. The resolution tree is unchanged
(231 yarn resolutions, byte-identical set; zero npm transitive drift);
only the root descriptor strings move from ranges to the versions
already resolved in the committed lockfiles.
Addresses the Codex P1 on #2503.
---------
Signed-off-by: Samar Tomar <samar_tomar@hotmail.com>
Co-authored-by: Samarjeet Singh Tomar <samartomar@gmail.com>
