julien/apf_portal
1
0
Fork 0
Code Issues 1 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

chore: rename project from adastra_portal to apf_portal

Browse Source 
The host organisation - APF France Handicap - was confirmed on
2026-04-30. Update all in-repo references to use apf_portal
(snake_case in prose) and apf-portal (kebab-case workspace name and
repo URL). Touched: CLAUDE.md, ADRs 0001/0002/0003/0015, and the Nx
bootstrap setup guide.

The historical name is preserved as a single sentence in ADR-0003 as
a self-validating example of the function-prefixed naming convention
designed exactly for this scenario - the apps (portal-shell,
portal-bff) and the lib conventions (feature-<name>, shared-<scope>)
were unaffected by the rename, which was the explicit point of
ADR-0003.

Memory state aligned out-of-band: project_adastra.md retired,
project_apf_portal.md created with the expanded APF context (host
org, health + financial data scope, ASVS L3 pending RSSI input, UI
stack decision spartan-ng + CDK + Tailwind, expanded phase-3 status).

Pending follow-ups (user-side, not in this commit):
- rename the Gitea repo julien/adastra_portal -> julien/apf_portal
- git remote set-url origin gitea@git.unespace.com:julien/apf_portal.git
- optionally rename the local working directory ~/Works/adastra_portal/
  -> ~/Works/apf_portal/
This commit is contained in:
Julien Gautier
2026-04-30 13:31:38 +02:00
parent 49712d0bbf
commit 880c7ded6b
6 changed files with 19 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
decisions/0003-workspace-and-app-naming-convention.md
+4 -4
View File
@@ -9,7 +9,7 @@ tags: [process]
## Context and Problem Statement
Default Nx scaffolding offers placeholder names like `my-workspace` and `web`, which are unacceptable for a long-lived enterprise project. Naming has to survive two foreseeable changes: the product's marketing name may evolve (the working title `adastra_portal` is provisional), and the project may sit alongside other R&D projects in the same Gitea organization, where collisions on generic names like `web` or `api` would cause confusion.
Default Nx scaffolding offers placeholder names like `my-workspace` and `web`, which are unacceptable for a long-lived enterprise project. Naming has to survive two foreseeable changes: the product's marketing name may evolve (the working title `apf_portal` is provisional), and the project may sit alongside other R&D projects in the same Gitea organization, where collisions on generic names like `web` or `api` would cause confusion.
What naming convention do we adopt for the workspace, the apps, and future libraries so names are explicit, function-anchored, and stable against rebranding?
@@ -24,7 +24,7 @@ What naming convention do we adopt for the workspace, the apps, and future libra
## Considered Options
* **Defaults** — `my-workspace`, `web`. (Rejected up-front.)
* **Brand-anchored** — `adastra-front`, `adastra-back`. Fragile to rebranding.
* **Brand-anchored** — `apf-front`, `apf-back`. Fragile to further rebranding.
* **Function-prefixed** — `portal-shell`, `portal-bff`. (Chosen.)
* **Generic** — `shell`, `bff`. Risk of org-wide collision; reduced readability.
@@ -34,13 +34,13 @@ Chosen option: **function-prefixed naming**.
| Scope | Name | Rationale |
| --- | --- | --- |
| Workspace / repo / npm package root | `adastra-portal` | matches the Gitea repository name; the only place a brand-ish name lives, so a rebrand is a one-line change |
| Workspace / repo / npm package root | `apf-portal` | matches the Gitea repository name; the only place a brand-ish name lives, so a rebrand is a one-line change |
| Frontend app | `portal-shell` | "shell" describes the function — the Angular host that loads features |
| Backend app | `portal-bff` | explicit role: backend-for-frontend |
| Feature libraries | `feature-<name>` | e.g. `feature-auth`, `feature-billing` |
| Shared libraries | `shared-<scope>` | e.g. `shared-ui`, `shared-data-access`, `shared-util` |
The `portal-` prefix encodes the *function* (a portal). Even if the brand `Adastra` is renamed, "portal" remains accurate. The brand-ish token `adastra` is confined to the workspace root and a tiny number of metadata files (root `package.json`, repo URL).
The `portal-` prefix encodes the *function* (a portal). The host organisation's brand can change without invalidating "portal" — the project was originally proposed as `adastra_portal` and renamed to `apf_portal` on 2026-04-30 once the host organisation (APF France Handicap) was confirmed; the apps `portal-shell` / `portal-bff` were unaffected by the rename, validating this convention. The brand-ish token `apf` is confined to the workspace root and a tiny number of metadata files (root `package.json`, repo URL).
### Consequences