polyforge.registry.toml

The registry is the one file in the PolyForge repository that knows about your work. It contains no code — only names and where to find them.

It is committed. That is what makes a fresh clone able to restore everything.

Schema

[learn.<lang>]

A learning track. The section name is the language, so no lang key is needed.

[learn.go]
repo = "git@github.com:youruser/learn-go.git"

Key	Required	Meaning
repo	yes	Git URL to clone from

Restored to Dev/Learn/<lang>/ by learn get.

[portfolio.<name>]

A project.

[portfolio.wall-extraction]
repo = "git@github.com:youruser/wall-extraction.git"
lang = "Python"

Key	Required	Meaning
repo	yes	Git URL to clone from
lang	yes	Which Workspace/<lang>/ directory to restore into

Restored to Workspace/<lang>/<name>/ by polyforge get.

[template.<name>]

A template.

[template.archon]
repo = "git@github.com:youruser/template-archon.git"
description = "archicad addons template"

Key	Required	Meaning
repo	yes	Git URL to clone from
description	no	Shown by forge list, including for templates not yet cloned

Restored to Dev/Templates/<name>/ by forge get.

Who writes it

Command	Writes
polyforge publish	a [portfolio.*] entry
learn publish LANG	a [learn.*] entry
forge new NAME "DESC"	a [template.*] entry

All three need gh. Nothing that only reads the registry — every get — needs more than git.

Commit after publishing

Publishing modifies this file in your working tree. If the change is not committed and pushed, the next machine cannot restore what you just published. Treat the registry commit as the last step of publishing.

Editing by hand

It is ordinary TOML and safe to edit. Common reasons to:

• Retiring something — forge remove deletes only the local copy. To retire a template properly, delete the GitHub repo and remove its section here.
• Moving a project between languages — change lang, then move the directory under the new Workspace/<lang>/.
• Repository renamed or transferred — update repo.

Conflicts

Publishing from two machines produces two additions to the same file, which git usually merges cleanly since entries are separate TOML sections. If it does conflict, keep both sections — order does not matter.