Canvas Ics33

canvas-ics33

Produce and verify one code-assignment artifact in any language. Treat the Canvas assignment summary as a routing hint; the real specification controls the work.

Runtime contract

Require an approved current plan item, its assignment snapshot, run_dir, and the exact work directory returned by:

from src.course_artifacts import ensure_stable_work_dir

work = ensure_stable_work_dir(run_dir, course_id, assignment_id)

The directory name must be course-<course_id>__assignment-<assignment_id>. Never use a course or assignment name as filesystem identity. Keep all assignment writes below it:

spec.md
spec-sources/
references/
repo/
draft/
REQUIREMENTS.md
constraints.md
research_findings.md
verification.log
audit/round-<n>.json
stages/
result.json

This skill handles code, code-adjacent short PDFs, and required development history. Route essays, reading annotations, zyBook problem sets, and quizzes to their dedicated skills. Use skipped only for an intrinsically manual task such as an in-person defense, identity check, or proctored environment.

Resolve the private course design

Read _private/canvas-ics33-app.md before fetching or generating anything. The file may contain several courses and assignment kinds:

1. Select the exact ## Course <course_id> block. Never inherit a similarly named course or another course's defaults.
2. Within that block, accept either a ### <kind> or #### <kind> heading. Match its naming_regex against the complete assignment name and retain all named regex groups for URL and filename templates.
3. Resolve explicit inheritance only inside the selected course block.
4. Validate all required and conditional fields before any download or command.

The course block supplies language and optional language_version. Each kind supplies these fields as applicable:

If the overlay, course block, or kind is absent, hand off to canvas-bootstrap for that exact course/kind. Resume only after the design is materialized and revalidated. If it remains unresolved, write error with reason_code=overlay_unresolved. Never copy private overlay values into this tracked skill or another public artifact.

Pipeline

Run the stages in order unless first-run stage mode is active. Preserve every intermediate artifact so a retry can resume from verified evidence.

1. Discover the real specification

Use the read-only Canvas helpers needed for the selected source chain:

from src import canvas_client as cv

assignment = cv.get_assignment(course_id, assignment_id)
front_page = cv.get_front_page(course_id)
modules = cv.list_modules(course_id)
syllabus = cv.get_syllabus_body(course_id)
files = cv.list_assignment_files(course_id, assignment_id)

Resolve spec_source as follows:

Follow relevant module items, syllabus links, attached files, and specification links until the deliverable is unambiguous. Save each source verbatim under spec-sources/ with source URL or Canvas file ID, retrieval time, and hash. Write spec.md with a verbatim section and a clearly labeled normalized summary. Preserve the original privately even if src.course_artifacts.redact_behavioral_rules is used for deliverable-shape analysis.

For a login-only optional source, ask for a user-provided link in interactive mode and record the outcome. Continue without it only when the specification proves it is nonessential. A missing required source is error; headless mode must not prompt or guess.

2. Fetch every referenced source

Apply every reference_fetch_patterns regex to the verbatim specification. For each match, use reference_resolver to retrieve the cited lecture note, textbook section, prior implementation, starter file, or other upstream source. Save the original artifact in references/ and record its origin and hash in references/manifest.json.

This stage is mandatory whenever the specification refers to an upstream source. Do not invent a signature, identifier, data shape, exception, or example. If a pattern matches and its source cannot be recovered, write error with reason_code=required_reference_unavailable. An empty references/ directory is acceptable only when the source scan records zero required references.

3. Acquire the scaffold and freeze protected content

Use the declared scaffold_distribution:

Hash every DO NOT MODIFY block, fixed exception/type declaration, starter filename, and submission helper before editing. Never modify the original download outside repo/.

Write REQUIREMENTS.md with one item per gradable requirement: deliverable names and types, interfaces, behavior, errors, required technique, forbidden constructs, rubric lines, source dependencies, and package contents.

4. Build the constraints checklist

Write constraints.md as atomic yes/no propositions with a verbatim source anchor. Include:

• every required filename, function, class, parameter, return type, and error;
• every must, must not, do not, allowed-import, and protected-block rule;
• every numeric phrase such as exactly, at most, no more than, minimum, maximum, page count, sentence count, function count, and coverage target;
• every specification example as an executable input/output assertion;
• every referenced identifier that must be grounded in spec.md or references/.

Name the measurement or parser that will verify each executable proposition. Do not reduce a numeric requirement to a subjective review.

4.5. Research before improvising

Trigger this stage for a new technique or output shape, an unfamiliar numeric constraint, a mismatch with the default pipeline, or relevant recent grader feedback. Spawn two or three bounded native Codex subagents in parallel and give them raw local artifacts rather than the current session's conclusions:

• literal-spec verifier: enumerate explicit requirements, constraints, forbidden items, and ambiguities from spec.md;
• quality inferrer: inspect the last five same-course results and available feedback, then propose mechanically checkable quality gates;
• template-fit checker: identify requirements not covered by Stages 5-8.

Save their separate findings and a synthesis to research_findings.md. Add supported requirements and checks to the two checklists. Preserve conflicts verbatim; never silently let inferred quality override a literal constraint.

5. Implement test-first

Plan small feature slices from the checklist. For each slice:

1. Add a test that fails for the missing behavior.
2. Run the overlay's test_runner and preserve the expected failure.
3. Implement the smallest grounded change without altering protected content.
4. Run the full test command and repair until green before the next slice.
5. If process history is enabled, commit only the green slice inside the assignment repository.

Add specification examples, boundary cases, error paths, and regression tests. Run the configured coverage command after all slices; add tests for genuinely uncovered requirements until the exact target passes. Never weaken starter tests, alter their expected values, or proceed with a failing suite.

6. Build optional process history

Skip this stage when process_severity: off or history is not a deliverable. Otherwise operate only on the assignment repository. Use the overlay's feature stages, session spacing, message register, and few-shot examples to turn the green Stage-5 checkpoints into the required development history.

When rebuilding local draft history, invoke Git with argument lists and set GIT_AUTHOR_DATE and GIT_COMMITTER_DATE in the child process environment. Preserve the configured author identity; never change global Git configuration or the product repository's history. Audit commit count, chronological order, message constraints, file diffs, and a clean final tree.