Publishing & forking a curriculum

There is no apprenti.dev backend, no catalog to publish to, and no login. A curriculum exists because a Git repository exists, and it spreads the same way any Git repository spreads: forking, cloning, and pushing.

Upstream and origin

The canonical curriculum lives in one repository (for the reference curriculum, the one listed in the curricula catalog). A mentor typically works from a fork that pairs with one apprentice — origin is that fork, upstream is the canonical repository it came from.

The app can fetch upstream, show what changed, and merge those curriculum updates into the fork — without touching apprentice or mentor personal-data folders. Ownership stays cleanly split:

• Curriculum content (manifest, tasks, resources, competencies, schemas) — curator/upstream-owned, safe to pull in.
• Apprentice and mentor personal folders — pair-owned overlay, never touched by an upstream merge.

Because of that split, pulling in a curriculum update never risks overwriting a reflection, a submission, or a review — a same-file conflict (two edits to the identical task, for instance) always surfaces for a human to resolve; it is never silently overwritten in either direction.

Sharing a curriculum you've authored or forked

There is no "publish" button, by design — the app never publishes or sanitizes a fork automatically. Sharing a derivative curriculum (as a new base for other mentors, say) is a deliberate, human Git operation:

• •Copy the shareable trees: the curriculum manifest, the curriculum content itself, resources, competencies, schemas, and the curriculum's own docs folder.
• •Do not copy the apprentice or mentor personal-data folders — those hold a specific pair's personal records, not curriculum.
• •Push to a new repository (or a new branch/fork) intended to be the next canonical or shared base.

That last step deserves care on GitHub: forking a public repository through GitHub's own Fork button always produces another public repository, with no way to change that afterward. If a mentor or apprentice working from your curriculum wants their working copy private, point them at Keeping your fork private — GitLab, by contrast, lets you pick a fork's visibility at creation time.

Deleting the apprentice and mentor personal-data folders from the working tree is the minimum. If those folders were ever committed, Git history retains them until you start a genuinely new repository or rewrite history — the app cannot do this for you, and won't attempt to guess when it's safe.

Where apprenti creator fits

Creator writes and validates the curriculum files; it deliberately leaves Git itself — remotes, commits, diffs, pull requests — to VS Code's or Cursor's own source-control tooling, the same interface a curator already uses for everything else in the repository. It may suggest a commit message; it never pushes anything on your behalf, and it refuses to write to the apprentice or mentor personal-data folders even if asked.

For a brand-new curriculum

Creator can scaffold either a single-curriculum repository or add a new curriculum into an existing multi-curriculum repository. Either way, a new curriculum starts with its own empty term and reuses the shared root resource and competency libraries rather than copying them — the library is meant to be shared across every curriculum in that working copy, not duplicated per curriculum.