Update to Agentic Course Redesign

{
  "name": "course-redesign-system",
  "description": "Review, validate, activate, schedule, pause, renew, or roll back the reusable agentic course-redesign system after a successful course run. Use for skills, plugin, AGENTS.md, custom agents, state schemas, memory, validators, runtime activation, or scheduled workflow contracts.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 260
    }
  ],
  "skill_md_contents": "---\nname: course-redesign-system\ndescription: Review, validate, activate, schedule, pause, renew, or roll back the reusable agentic course-redesign system after a successful course run. Use for skills, plugin, AGENTS.md, custom agents, state schemas, memory, validators, runtime activation, or scheduled workflow contracts.\n---\n\n# Course Redesign System\n\n## Lecturer Decision Dialogue Contract\n\nThe orchestrator is the sole lecturer-facing interface; specialist roles are\nevidence lenses and return questions through it. Ask one unresolved\nconsequential question at a time. Before using a native choice card, follow the\nlive host tool contract. Use a card only when it can present the complete,\nmutually exclusive option set and a custom-answer path without omission. Never\nprune, hide or combine valid choices merely to fit a card. If a native card is\nunavailable or unsupported, its capacity is unknown, or the complete set\nexceeds that capacity, ask the same single question in ordinary chat with every\nvalid numbered option plus `Other - type your answer`, then wait. Every valid\noption remains visible. For very\nlong decisions, use adaptive dependency-based clusters only when choices share\nevidence or constrain one another: keep every valid option visible, explain the\ngrouping and let the lecturer split, merge, reorder or rename it. For example,\noutcomes, assessment evidence, permitted AI use and learning activities belong\ntogether when mutually dependent; student-experience, accessibility and\nactive-learning perspectives may be clustered when participation design\njointly affects usability, inclusion, workload and engagement.\n\nPreserve a custom answer exactly, confirm its canonical interpretation, reflect\nthe consequence, and maintain a decision ledger in the chat and current state.\nShow an editable recap at each cluster or gate end. A skipped or blank response\nleaves a required question unresolved. The safest truthful, evidence-aligned,\nreversible option may be marked `Recommended`, but never preselected; factual\ndeclarations must say \"select only if true,\" and uncertainty fails closed. At\nmajor pedagogical gates, ask for the lecturer's criteria and preliminary view\nbefore recommending when practical. Exact authority gates and approval tokens\nremain separate and unchanged; a dialogue choice never substitutes for them.\n\nCourse-material acceptance and system activation are separate decisions. Never update the live system merely because a course run succeeded.\n\n## Required successful-run evidence\n\nBefore any system review, verify one closed `complete_dormant` current-lineage run with all of the\nfollowing durable records: valid production declaration; matching Production\nHandoff approval; independently verified handoff; accepted HITL 3 (including\nverification of any named conditional corrections); and a system-improvement\nreview offer whose status is `requested`, plus the explicit response and\nterminal closeout receipts. Top-level `active_run_id` must no longer name that\nrun. Reject stale or mixed run, contract, task/chat, shared-context,\neligibility, manifest, source-policy or plan lineage. System work is separate\nfrom the closed course run.\n\nThe offer must have presented the complete mandatory scope and been recorded\nbefore it was asked. On resume, never ask it again when its status is\n`offered_awaiting_response`, `requested` or `declined`. A request authorises only\nread-only comparison of run evidence with the current reusable system and one\nversioned proposal. It does not authorise system-file changes, installation,\npublication, release, activation, schedule registration or modification, an\nimmediate run, or any new MCP server, connector, authentication, permission or\nexternal egress.\nSilence remains `offered_awaiting_response` and closes nothing. An explicit\nrequest or decline closes the course run as terminal `complete_dormant`, clears\n`active_run_id`, prevents resumption and persists one informational trigger-\nguidance offer. Decline ends system action; request opens only separate system\nwork.\n\nThe recorded question must be exactly:\n\n> Would you like a separate, read-only system-improvement review covering the workflow skills and umbrella entry routing; plugin or platform adapter; AGENTS.md and agent configurations; project template, state schema and migration; validators, tests and QA; documentation; memory or other workflow-owned durable instruction stores; schedule contracts; permissions, tools, external egress and automatic behaviour; and compatibility, benefits, regressions, risks, residual risks and rollback, followed only by a versioned proposal? A yes authorises only that review and proposal; it does not authorise system-file changes, installation, publication or release, runtime activation, schedule registration or modification, an immediate run, or any added MCP server, connector, authentication, permission or external egress.\n\n## Improvement proposal\n\nAfter those prerequisites pass, compare actual run evidence with the current\nskills and umbrella route; plugin or platform adapter; `AGENTS.md` and agent\nconfigurations; project template, state schema and migration; validators and\ntests; documentation; memory or other workflow-owned durable instruction\nstores; schedule contracts; permissions, tools, egress and automatic behaviour;\nand compatibility and rollback. Propose changes under a unique proposal\nID/version with:\n\n- problem demonstrated by the run;\n- affected system files;\n- exact proposed change;\n- benefit and possible regression;\n- migration/compatibility impact;\n- tests and success criteria;\n- residual risk and rollback; and\n- lecturer choices: keep current, revise proposal, or validate candidate.\n\nDo not include course content, answer keys, personal data, or copyrighted assets in the reusable plugin.\n\n## System gate and validation\n\nCreate changes only after a separate completed System Gate reply with exact\ncurrent lineage, proposal ID/version, validation evidence and exact targets,\nand `APPROVE SYSTEM FILES` as a standalone line. A token-only reply is invalid.\nKeep the result in an inactive candidate. Validate\nmanifests, JSON/TOML/YAML, skill structure, setup preview/apply/no-overwrite\nbehaviour, manifest hashing, lineage rejection, gate ceilings, answer-key\nboundaries, target restrictions, retry rules, migration preview behaviour and\ndocumentation. Forward-test in a disposable course folder and verify the\noriginal candidate and test fixtures remain unchanged.\n\nThe System Gate may approve an activation-ready candidate, but never activates it. Record the exact proposal ID/version, validation run and evidence, residual risk, and rollback reference.\n\n## Separate runtime activation\n\nActivation requires a later lecturer decision naming the exact validated proposal ID/version. Missing or stale lineage leaves top-level state `candidate_not_active`. Activation, keeping inactive, and revise/revalidate are all valid choices.\n\n## Standing schedule contract\n\nDo not register a schedule until the runtime is active and the contract binds to that exact activated version and current Gate-0A eligibility fingerprint. Present a complete versioned contract containing exact course/project, task type, canonical mission, goals/non-goals, success/stop criteria, tools/actions, source classes, audiences, eligibility fingerprint, source-policy version/fingerprint, assessment-security boundary, protected root, lecturer-confirmed IANA timezone, recurrence, gate ceilings, retry/escalation/termination rules, unique output naming, no-immediate-run rule, activation reference, and non-null expiry.\n\nRun a no-write simulation first: no registration, trigger, web call, or file change.\n\nFreeze the complete visible contract before approval. Store its validator-derived canonical SHA-256 as `approved_contract_snapshot_reference`, use offset-bearing `YYYY-MM-DDTHH:MM:SS+HH:MM[IANA/Timezone]` activation and expiry values, and recheck the snapshot, runtime, policy and expiry before registration and every recurrence.\n\nRegister only after one lecturer reply containing exactly and only these completed lines with matching values:\n\n```text\nAPPROVE SCHEDULES\nSchedule contract: <exact contract ID and version>\nExpires: <exact local date and time with IANA timezone>\n```\n\nApproval registers the schedule but never triggers an immediate content run. Each recurrence creates a fresh run and lineage containing the current eligibility fingerprint, then revalidates eligibility, sources and policy, waits at its first required gate, and stops at its stage ceiling. Eligibility change, expiry, material changes, stale baselines, or mismatched runtime/source lineage fail closed and require reconfirmation. Pause is explicit; renewal requires a new version, eligibility binding, expiry, simulation and approval; rollback disables scheduling and preserves history.\n"
}