| Access role |
Installation-wide permission bundle, such as admin, contribute, user, or an admin-defined access sub-role; managed in Admin → Members & Permissions |
| AS-IS / TO-BE KB |
Knowledge base of the current / target system: the documents of the document repository. Members' agents reach it through the Brain |
| Brain |
The tree index of one branch of a project's document repository: folders, documents, sections and cards with a summary each, no vectors. Agents reason over it and cite path, lines and commit (reference, ADR-0091) |
| Code repo |
Umbrella term for source and target repos. A project usually has many, possibly on different Git servers |
| Common component |
Something every unit reuses, designed once by the foundation team: a document 02-architecture/common/COM-<AREA>-<NN>.md; unit designs refer to it by id (ADR-0044) |
| Design set |
A group of design documents written together for a unit (for example the basic design and the detail design), defined by the project as templates with checks in 01-standards/templates/<set>/ (design templates, ADR-0045) |
| Digital worker |
An AI work profile such as reverse design, code generation or unit-test generation. In Kintsugi it is an agent plugin plus a task-pack template, run in a member's harness, with runtime agents preparing and reviewing the work |
| Foundation team |
The project role that designs what every unit shares (the architecture, the common components, the skeleton) before the units are designed; a name in the pipeline, not a kind of actor |
| Gate |
Quality / approval checkpoint: G0–G4 per phase, plus per-unit gates |
| Harness |
An environment that runs an AI agent (pi, Claude Code, GitHub Copilot, Codex…) |
| Installation |
One self-hosted Kintsugi instance (Docker Compose), serving one organization |
| Kintsugi Runtime |
Kintsugi's agent environment, built on pi; runs in the worker, one job workspace per job |
| Job workspace |
<data>/jobs/<id>/: one per job, kept across its attempts. The read-only checkouts of the legacy code (as-is/<repository id>/) and the target code (to-be/<repository id>/) and documents (docs), the results (out, work), a folder per step (steps/<step>/), the guide WORKSPACE.md, the manifest workspace.json and the ledger .state/ledger.json; the isolation boundary of runtime jobs and script steps, without an OS sandbox (ADR-0029, ADR-0055, reference) |
| Attempt |
One run of a job in its workspace. A retry of a failed stage run is the next attempt of the same run, not a new run; the steps whose fingerprint did not change are not run again (ADR-0055) |
| Member harness |
The AI tool a member uses locally: Claude Code, GitHub Copilot, ChatGPT/Codex |
| Pipeline definition |
The phases, stages, performers and gates an application follows: built-in, or declared in kintsugi.yaml |
| Pilot unit |
A unit flagged pilot: true, run first to check the project's standards before work at scale |
| Project build |
Setting a project up: create or join the document repo, register the AS-IS and TO-BE repos, write the standards |
| Project role |
RACI responsibility from @kintsugi/domain, such as pm, architect, dev, qc or ai-champion; pipelines may name their own; assignment per project membership is planned with M0 project persistence |
| Rebuild |
What Kintsugi does with every application: it is re-created on a new architecture from what its legacy system does (reverse engineering first, then the later phases). There is no per-application choice of strategy |
| Runtime agent |
A platform agent executed by the runtime kernel: an agent definition (instructions, skills, tool allowlist) supplied with each job. Built-in agents cover the understanding phases (legacy-analyst, business-rules-extractor, architecture-critic, security-auditor); admins create more in the Agent Builder (ADR-0026) |
| Scorecard |
Weighted assessment of an application across business, technical, feasibility, cost and risk criteria |
| Legacy repo |
A legacy code repo; always read-only for the runtime |
| Agent plugin |
A package in the Claude Code plugin format (.claude-plugin/plugin.json + skills, agents, commands, hooks, MCP) installed into member harnesses; the built-in one is kintsugi |
| Catalog item |
One entry of an application's assessment catalog (<module>/<item>); once selected it becomes a unit. Use item only for catalog entries |
| Hook |
A plugin component that runs on harness lifecycle events (session start, before / after tool use, stop), e.g. the write guard and activity reporting |
| Marketplace |
A generated marketplace.json listing published plugins for a harness; document-repo marketplace generation is planned and the output is never hand-edited |
| Skill |
An Agent Skills folder (SKILL.md) inside a plugin, namespaced <plugin>:<skill> |
| Target base |
The target repo as scaffolded by the solution architect (framework, layering, conventions, CI) before units are converted into it |
| Task pack |
Context for one unit (spec, AS-IS excerpts from the KB, rules, acceptance criteria, suggested skills) for a member's harness |
| Unit |
The thing being migrated, identified by the full <app>/<module>/<unit>; what is known about it lives in 10-applications/<app>/01-legacy/<module>/<unit>/, its card and design in 10-applications/<app>/02-modern/<module>/<unit>/ (ADR-0051) |
| Unit card |
10-applications/<app>/02-modern/<module>/<unit>/README.md in the document repo; its frontmatter is the unit's state (ADR-0012, ADR-0051) |
| Wave |
A group of applications or units migrated together, by pattern |
| Work item |
Legacy API/domain term corresponding to a unit. Use unit in documentation; existing API/CLI names are unchanged. |
| Document repo |
The project's single Git repo for everything except code; Markdown only, numbered in reading order with each application split into a legacy and a modern half; see the layout reference for current paths and planned homes |
| Unit aggregate |
A unit's two folders, 01-legacy/<module>/<unit>/ and 02-modern/<module>/<unit>/, with the card README.md as its root; each context writes into its own folder; see document repo contexts |
| Scratch |
The JSON a run passes between its steps, under scratch/<app>/ in the job workspace; never committed |
| Legacy repo |
An AS-IS repo with role legacy (code) or legacy-data (data); always read-only for Kintsugi |
| Standards |
The project's target conventions, mappings and review rules: plain documents in 01-standards/ of the document repo |
| Target repo |
A TO-BE repo with role target, implementing one architecture component; only members write to it |