Plumego is not only a set of Go packages. It has a control plane that tells humans and agents how to classify work before editing code.
Read Reference App first if the question is still service assembly. Use this page once the question becomes ownership.
docs -> explain intent and learning path
specs -> define machine-readable boundaries
tasks -> scope execution and validation
code -> implement the classified behavior
| Question |
Source of truth |
Example files |
| What is the intended path for humans? |
Docs |
website/src/content/docs, docs/reference/canonical-style-guide.md |
| Which module owns this work type? |
Specs |
specs/task-routing.yaml, specs/extension-taxonomy.yaml |
| Which imports are allowed? |
Specs |
specs/dependency-rules.yaml |
| What is in scope for a milestone? |
Tasks |
tasks/milestones/active/M-NNN-short-name/M-NNN.md |
| What does a runnable service copy from? |
Reference app |
reference/standard-service |
| What does a package promise locally? |
Module manifest |
target <module>/module.yaml |
| Work type |
Start here |
Then check |
| Kernel, lifecycle, route attachment |
Stable root primer |
target module module.yaml |
| Transport contract, error model, response shape |
contract primer |
call sites and docs snippets |
| Optional capability, protocol, tenant, gateway, data, or observability work |
Owning x/* family |
release posture and extension maturity |
| App-local bootstrap or wiring |
reference/standard-service |
service-local tests and route map |
| Repo rule, boundary, or execution sequencing |
docs, specs, or tasks |
relevant checker or milestone acceptance criteria |
| Step |
Check |
| 1 |
Which stable root or x/* family owns the behavior? |
| 2 |
Which docs page explains the intended path? |
| 3 |
Which spec constrains routing, taxonomy, or dependencies? |
| 4 |
Which module manifest defines local scope and checks? |
| 5 |
Which task card or milestone defines done, if the work is milestone-scoped? |
| Not this |
Use this instead |
| Package-level API reference |
The package docs and module primer |
| Permission to skip module manifests |
The touched module’s module.yaml |
| A release compatibility promise |
Release Posture |
| A runnable-service tour |
Reference App |
