Canvas Bootstrap

Canvas Bootstrap

Turn one student-selected recurring pattern into a durable Codex course skill. This is a detective and authoring workflow, not a pending-work scanner and not a submission workflow.

Bootstrap is intentionally scope-first: one selected candidate, one course, one route per invocation. The student may run it again for another pattern later.

Entry contract

Normal first-run entry requires all of the following:

1. Canvas authentication has already been verified by canvas-setup.
2. canvas-skill-opportunity wrote the private local runs/<today>/skill-opportunities.json and companion Markdown report.
3. The student explicitly selected one numbered candidate in a later turn.

The opportunity report is evidence, not authorization. A ranking does not authorize skill creation by itself, does not approve any pending assignment, and grants no upload, submission, or quiz-mutation authority.

A manual redesign request may target one existing route without a fresh opportunity report, but Bootstrap must still run the same current-evidence and viability checks and must ask before replacing a working skill or private overlay.

If invoked with no selected candidate and no explicit redesign target, stop and ask for the candidate number. Do not choose the top-ranked item for the student.

Outputs and privacy split

On a successful run, Bootstrap may create or update exactly these local surfaces:

• .agents/skills/canvas-<safe-name>/SKILL.md — tracked, public-safe workflow instructions with no private course facts;
• _private/canvas-<safe-name>-app.md — gitignored local overlay containing the real course mapping, source locations, material pointers, measured checks, calibration state, and user preferences;
• courses.yaml — local route configuration, updated atomically only after the skill is ready.

Keep .claude/ read-only. It may be inspected as frozen behavioral history when needed for parity analysis, but no content from private legacy playbooks may be copied into the public Codex skill. Do not write .claude.

Private identity, institution, real course and assignment identifiers, teaching staff details, private URLs, feedback text, prior answers, and exact grades stay in gitignored local state. Chat uses the opportunity number and a neutral alias.

Hard boundaries

• Do not scan all pending work or create plan.json.
• Do not call canvas-scan or canvas-execute from Bootstrap.
• Do not start, answer, or complete a quiz attempt.
• Do not upload or submit anything.
• Do not create a route before student selection and the viability gate both pass.
• Do not mark a skeleton, TODO file, empty document, sentinel, placeholder, or template-only output as draft_ready.
• Do not infer the real spec from assignment name or description alone.
• Do not turn recurrence, points, or opportunity tier into a grade promise.

Phase 1: Resolve the selected opportunity

Read the current private opportunity report and resolve the student's number exactly. Verify against current read-only Canvas metadata that:

• the candidate still belongs to one course;
• its representative pattern still exists;
• the course is active (is_course_active(..., grace_days=7); ended courses outside that grace period are ineligible);
• the candidate has not already been superseded by a working route;
• its opportunity evidence was based on representative real specifications, not names or metadata alone.

Reject cross-course combinations. If the student selected several patterns from the same course, proceed only when they share one repeatable workflow and one verification model; otherwise ask them to select one.

If the candidate disappeared or materially changed, do not silently substitute another. Explain the drift and return to canvas-skill-opportunity for a fresh report.

The full-course fingerprint triage belongs to canvas-skill-opportunity, not Bootstrap: it may use bucket_recurring(..., min_freq=3) and divide evidence into main, likely-real, and noise groups, with noise hidden by default and too-little-history candidates labeled lower-confidence. Bootstrap consumes the student-selected report entry and must not turn empty routes into a second, competing ranking pass.

Phase 2: Re-investigate the real workflow

Opportunity analysis is intentionally lightweight. Bootstrap must re-read the chosen pattern deeply before authoring anything.

Sample at least two representative assignments when available, including the most recent and one older instance. For each sample, follow every relevant pointer from the Canvas description to the actual source of truth:

• assignment attachments;
• course front page and syllabus pointers;
• module pages and linked files;
• external specification pages;
• rubric or grading criteria;
• submission/delivery format.

Treat the assignment title and description as routing hints. Do not assume a thin description is complete.

For every sample, perform a three-part reachability check:

1. the real instruction source is identified;
2. every required referenced material is located;
3. each located source can actually be read or downloaded without a live attempt or other mutation.

Name every missing or login-locked source in one concise clarification. Never turn a missing source into a silent “unknown.” If the student cannot provide a required source, the viability gate fails.

Read-only quiz policy projections may be used when the opportunity involves a quiz: allowed attempts, feedback timing, answer visibility, and scoring policy. Never start an attempt to discover those facts; do not retain raw answers, answer identifiers, private feedback bodies, or exact scores.

Phase 3: Design and independent review

Draft a private workflow model containing:

• how the real spec and required inputs are found each run;
• ordered production stages;
• the concrete local deliverable or explicit manual handoff;
• measurable verification checks that write verification.log;
• optional polish/review behavior;
• canonical result.json outcomes;
• failure and retry limits;
• the intended existing base capability, when one applies.

Verification checks must return numbers or yes/no results. “Looks good,” “follows the rubric,” and similarly subjective placeholders are not checks.

Use native Codex subagents for three bounded reviews. Run rubric-coverage and verification-checklist review in parallel, then run the feasibility simulation against one representative sample after their findings are incorporated:

1. Rubric coverage reviewer — enumerate every requirement and identify workflow omissions. Revise and re-review up to two times.
2. Verification designer — produce specific measurements and thresholds; add a noisy failure check for any residual uncovered requirement.
3. Feasibility simulator — map each workflow step to available inputs and concrete outputs, then map every output to a check. Revise and re-run once when a step, output, or check is orphaned.

These are Codex native subagent handoffs, not Claude Agent(...) calls and not shell-launched model sessions. Give each reviewer only the sanitized evidence needed for its role. Keep reviewer transcripts and private evidence out of the tracked skill.

Categorize review findings before talking to the student:

• resolved implementation details go silently into the workflow;
• choices that change the delivered content or user experience go into one batched question;
• low-confidence engineering branches go into private calibration notes.

Do not dump reviewer JSON or internal workflow tables into chat.

Phase 4: Viability gate

All six conditions must be true before a skill can become ready:

1. Real instructions have a stable, reachable location.
2. Every required input/material is reachable or has an explicit manual handoff.
3. The response workflow repeats in substance, not merely in assignment naming.
4. The deliverable can be produced locally without an unauthorized Canvas mutation.
5. Completion checks are measurable and can write an all-PASS-or-fail verification.log.
6. A public-safe workflow can be separated cleanly from the private local facts.

Intrinsic impossibilities such as a proctored/LockDown environment or mandatory in-person identity action fail the gate for automation and route only to manual handling. A source that neither Codex nor the student can obtain also fails.

When the gate fails:

• do not write a ready route;
• if a scaffold was created, retain <!-- UNFILLED_SKELETON v1 --> and make its dispatch guard return canonical status: "error" with deferred_to_next_run: true;
• explicitly state which gate failed;
• offer the next candidate from the saved opportunity report;
• stop without executing an assignment.