fix: restore the external names the hierarchy rename rewrote - #107
Merged
Merged
Conversation
ExtraToast
added
type: bug
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.
Follows #100. Found while starting #82.
What this branch does
The hierarchy rename in #100 replaced Service, Workload and domain in their model sense. It also rewrote names that belong to other systems and happen to contain the word "service". Those names are not model vocabulary and must keep their spelling, because a reader copies them into a manifest, a policy or a search. This branch restores them, in 22 files, and changes nothing else.
serviceAccountName,.spec.serviceAccountNameapplicationAccountName${identity:serviceAccount},serviceAccount:applicationAccountbound_service_account_names,bound_service_account_namespacesbound_application_account_*OTEL_SERVICE_NAMEOTEL_APPLICATION_NAMECAP_NET_BIND_SERVICE,NET_BIND_SERVICECAP_NET_BIND_APPLICATIONservice-overview,service-templateapplication-overview,application-templatekubernetes-workload-fragment,src/deployment/render/workloads.ts,src/schemas/service-intent.ts,ServicePermission.kt,service.ymldeploy-config-schemaand another repository, as they were namedreview/PLACEMENT-DOMAIN-MANIFEST.mdreview/, which the rename did not touchPLACEMENT-PROJECT-MANIFEST.mdVerification
git show 7855d44^was the source for every restored spelling.git grep -E 'applicationAccount|bound_application_account|OTEL_APPLICATION_NAME|NET_BIND_APPLICATION|ApplicationPermission|kubernetes-process-fragment|PLACEMENT-PROJECT-MANIFEST'finds nothing.E_DUPLICATE_APPLICATION_IDand its siblings) or emphasis in comments (one per PROCESS).npm run verifyexit 0, 313 tests;link lint: 175 files clean.