refactor: rename the authored hierarchy to Project, Application and Process - #100
Merged
Merged
Conversation
ExtraToast
added
type: refactor
This was referenced Sep 14, 2026
ExtraToast
added a commit
that referenced
this pull request
Sep 15, 2026
…er 10 (#119) * docs: fix the platform example README's leftover Traefik Application and missing hardening row The tiers table cell still read "Application" where #100's rename should have left the Kubernetes Service alone; #107 restored other external spellings but missed this one. Also add the row for platform.intent.yml's hardening block, which the table never carried: one posture for every container, no per-control exception surface, decided by 0016. * docs: stop the data example's rendered README from writing alertClass: none Chapter 10 is explicit that Alert Class has no none member: an omitted observability block already says "no monitoring", and a member that means "I wrote the field to say I did not want the field" is ceremony. valkey's row said the Application "declares alertClass: none", which is not a value this schema accepts; it declares no observability block at all. * docs: make the negative fixtures' missing .project.yml suffix a stated convention spec/v1/examples/negative/*/intent*/ fixtures stand in for Intent Fragments already handed to composition, not files in a repository's platform/ tree, and renaming them to .project.yml would pull them into three tests that discover project files by that suffix, at least one of them (duplicate-process-name) failing where those tests expect every file to parse clean. Renaming is left for its own change; this commit instead states the convention in chapter 10 so the suffix difference reads as a rule rather than an oversight, and none of the three tests' selections move: 14 .project.yml files for the diagram test, 4 cases for the Project Intent test, and (by inspection of its source, without running Maven) 4 files for the EMF worked-examples test, which walks the same suffix excluding refusals/. * docs: finish the hierarchy rename in chapter 10's selector sentence The label-set section's hypothetical alternate labelling reads "would make every Process of a multi-Process Service selector-ambiguous". Before #100 this said "multi-Workload Service"; the rename converted Workload to Process but left this one "Service" unconverted, where it names what the estate now calls an Application (compare "a two-Process Application" in chapter 30) rather than a Kubernetes Service, which the surrounding paragraph never mentions: it is about a Deployment's pod selector. It now reads "multi-Process Application". Re-grepped spec/v1/*.md for Service used as the retired hierarchy word: the three remaining occurrences (10-project-intent.md's IngressRoute paragraph, 30-deliverables.md's adapter table, 16-dependencies.md's diagram node) are all the Kubernetes object and are left alone.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #35. Lands before the Task 0 proposal update, which will use these words.
What this branch does
The authored hierarchy is renamed: Domain, Service and Workload become Project, Application and Process, and the layer-1 document Service Intent becomes Project Intent. No decision changes. ADR
0116records why, and every ADR that used the old words carries an amendment note.Each old word already meant something else. "Service" had five meanings across deployment tools: a network endpoint (Kubernetes), an independently released unit (Compose, ECS, Railway, Cloud Run), a microservice (Dapr), an add-on (Heroku) and a port section (Score). The rendered output also contains Kubernetes
Serviceobjects, so one chapter used one word for two things. "Domain" reads as a DNS name in a model that authors hostnames. "Workload" means one runnable part in Kubernetes and the whole bundle in Score. The replacements are the common names for the same concepts: an application is the unit several processes are released in (Heroku, Fly.io, Cloud Foundry, OAM, Radius), a process is one runnable part (Heroku, Cloud Foundry, Fly.io), and a project is one file holding several apps (Compose, Railway).The rename reaches authored syntax, because nothing parses it yet:
domain,services,workloadsand the edge and route keys becomeproject,applications,processes,applicationandprocess, and*.domain.ymlbecomes*.project.yml.E_DUPLICATE_DOMAIN,E_DUPLICATE_SERVICE_ID,E_DUPLICATE_WORKLOAD_NAME,E_UNRESOLVED_SERVICEandE_WORKLOAD_RBAC_GRANTbecome their Project, Application and Process forms.10-project-intent.md. Nine model ADR files, the chapter 10 diagram, the negative fixture directories and the publish workflow example are renamed; ADR numbers are unchanged, so a citation by number still resolves..drawio.svgfiles say Project, Application and Process.The decisions later tickets inherit
Layer 3 keeps the target's spellings. A rendered
workload.yaml, a KubernetesService,ServiceAccountandServiceMonitorare untouched, as0097already requires. No rendered manifest byte changed.Three words keep a second meaning, recorded in
CONTEXT.md. Service, Workload and Domain are listed as retired model words. "Domain" stays for DNS names, ADR decision domains and the compiler hexagon's core ring (src/domain, ADRs 0065 and 0066). "Application" and "process" are also ordinary English, and the hexagon has anapplication/ring; the capitalised word is the model level.Historical evidence is not rewritten. Citations of files from the previous schema (
knowledge.service.yml:110, theservice-repov2 shape,spec.workloads) keep the names those files had.review/anddocs/mde/are untouched.Tickets. 25 open issues were rewritten with the new words on GitHub, including the titles of #38 and #84. Their links to renamed ADR files resolve once this merges.
Verification
npm run verifyexit 0:ADR lint: 93 files clean,link lint: 171 files clean,requirements lint: 14 rows clean,rules lint: 60 rules clean, 19 pending,docs lint: 31 claim(s) clean, 305 tests passed, coverage unchanged.node scripts/lint-adrs.ts emfreports9 files clean.Service,Workloadanddomainin the specification was listed and checked by hand: what is left is the Kubernetes object, a rendered file name, a cluster DNS domain, a decision domain, or a historical citation.