Release CARL 0.21.1 integration and plugin fixes

.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "carl",
-  "version": "0.21.0",
+  "version": "0.21.1",
   "description": "Coherence-Aware Reinforcement Learning and bidirectional local agent workflows.",
   "author": {
     "name": "Tej Desai"

.claude/skills/terminals/carl.md

@@ -9,10 +9,43 @@ Use the installed CARL MCP tools when available. Use the CARL CLI otherwise.
 CARL means Coherence-Aware Reinforcement Learning.
 
 1. Inspect the current project and the requested outcome.
-2. Use `validate_config` before starting training.
-3. Use observe and eval to measure the result the user requested.
-4. Use `list_skills` and `run_skill` for existing CARL workflows.
-5. Use `list_agent_harnesses` and `delegate_agent` when another native agent should do part of the work.
+2. For a goal, use `prepare_training` before starting training. Schema validation
+   alone does not establish data, graders, reward hooks or resource readiness.
+3. Present the prepared inputs, task checks, policies, model, limits and effects.
+   Pass the returned `plan_id` as `prepared_plan_id` to `start_training` or
+   `submit_async_training` only after the user has authorized that run.
+4. Keep execution completion separate from candidate acceptance. Return the
+   checkpoint, baseline comparison, acceptance reasons and reuse instructions.
+5. Use `list_skills` and `run_skill` for existing CARL workflows.
+6. Use `list_agent_harnesses` and `delegate_agent` when another native agent should do part of the work.
+
+## Goal preparation
+
+Discover the project root, selected interpreter, existing pipeline and relevant
+task fixtures. Preserve the model, backend and pipeline choices. Ask only for
+information the project cannot supply, one question at a time. Offer the two
+requested Tinny modes; keep universal-role ablation in advanced details.
+
+Prepare compatible local data with stable task IDs and separate held-out tasks.
+Use existing data adapters, verification records and kits. Reuse executable
+project checks and source references. Never substitute unrelated datasets,
+invent a grader, infer task success from answer length or move legality, or
+describe a simulated environment as an independent verdict.
+
+Resolve readiness issues before submitting. Missing model/data inputs need an
+authorized preparation action. Missing dependencies need an explicit install
+proposal. The first qualified goal integration uses local TRL; other backends
+declare their capabilities. Python pipelines can attach explicit reward and
+evaluator callables to the existing trainer and eval runner.
+
+Translate relevant user policies into explicit checks or existing execution
+controls. State which rules are measured and which are enforced during tool
+execution. A description in a prompt is not an executed policy check.
+
+Repeated prepared submission reuses its recorded result. Explicit resume uses
+recorded checkpoints; unresolved execution custody needs reconciliation.
+Retain metadata and approved artifacts. Do not use raw conversation exports,
+credentials or hidden reasoning as automatic training data.
 
 Local plugin access is FREE. Scheduled autonomy, paid services, publication, and
 private-runtime operations retain their own authorization and entitlement checks.

.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "carl",
-  "version": "0.21.0",
+  "version": "0.21.1",
   "description": "Coherence-Aware Reinforcement Learning and bidirectional local agent workflows.",
   "author": {
     "name": "Tej Desai"

CHANGELOG.md

@@ -1,5 +1,17 @@
 # Changelog
 
+## [0.21.1] - 2026-10-08
+
+- Authenticate private HF Jobs script fetches and keep submission tokens out of CARL logs and error messages.
+- Remove all environment/secret key collisions before job submission.
+- Accept legacy project `backend` fields as `adapter` while preserving explicit current fields.
+- Resolve preparation datasets beside the config before the project root and bind that config for replay.
+- Hash checkpoint files with bounded concurrency and cache SHA-256 digests by file identity and change timestamps. Execution still validates full source bytes.
+- Apply terminal privacy penalties outside cascade masks and reward weights; reject public trajectories exposing private draft identifiers.
+- Remove retired installer-owned skill references during plugin updates and preserve edited files.
+- Preserve an existing canonical Git-backed Codex marketplace during plugin updates instead of conflicting with its registration.
+
+
 ## [0.21.0] - 2026-10-08
 
 - CARL now installs as the `carl` plugin and skill for Codex, Claude Code, OpenCode, and portable MCP clients.

README.md

@@ -78,6 +78,34 @@ Full extras matrix, reproducible installs via `uv.lock`, and conflict rules (e.g
 
 ## Agent plugin
 
+CARL is a training and reinforcement-learning agent and harness for improving
+models toward your goals and policies through your existing AI tools and
+training pipeline. It prepares the inputs, adds coherence signals, evaluates
+the candidate against its starting model, and returns a reusable artifact.
+
+In your agent, ask CARL to improve a model for a particular task. CARL prepares
+the experiment before training and shows the inputs, limits and missing pieces.
+Task results, policy checks, coherence and cost stay visible separately.
+
+For the first qualified local TRL integration:
+
+```bash
+carl train --prepare --goal "Improve held-out task success" --config carl.yaml
+carl train --prepared-plan Eprep_YOUR_PLAN_ID --config carl.yaml
+```
+
+Preparation reads local model bytes and JSON/JSONL task examples, binds the
+held-out split and grader, and records a repeatable experiment. It does not
+download a model, install packages, submit a job or publish. Its readiness
+response distinguishes source checks from actual training and evaluation.
+Declare output policies in the goal's `policies` list. Existing execution
+permissions remain in force. Public publication is separate.
+
+The MCP equivalents are `prepare_training`, `start_training` and
+`submit_async_training`, with the prepared experiment ID on submission.
+Python callers can provide `task_reward_funcs` to `CARLTrainer` and `evaluator`
+plus `primary_metric` to `EvalRunner` without replacing their training loop.
+
 From a CARL checkout:
 
 ```bash