docs(style-guide): bring the public guide to the platform taxonomy

src/content/docs/en/pages/style-guide/components.mdx

@@ -145,8 +145,8 @@ A diagram is a `mermaid` code fence, not an image. The text reaches an agent fet
 ````md
 ```mermaid
 flowchart LR
-  Client --> Edge[Edge node]
-  Edge --> Origin[Origin server]
+  Client --> DC[Azion data center]
+  DC --> Origin[Origin server]
 ```
 ````
 
@@ -226,7 +226,7 @@ import DocItem from '@aziontech/webkit/doc-item'
 
 <FrameBox>
 <ItemList>
-  <DocItem title="Cache Settings" href="/en/documentation/build/cache/cache-settings/">How an edge node decides what to keep and for how long.</DocItem>
+  <DocItem title="Cache Settings" href="/en/documentation/build/cache/cache-settings/">How a data center decides what to keep and for how long.</DocItem>
   <DocItem title="Rules Engine" href="/en/documentation/platform/applications/rules-engine/">Conditions and behaviors on the request and response phases.</DocItem>
 </ItemList>
 </FrameBox>
@@ -274,7 +274,7 @@ A term in running prose that shows its definition on hover or focus, with an opt
 ```mdx
 import DocTooltip from '@aziontech/webkit/doc-tooltip'
 
-The <DocTooltip client:visible headline="Cache key" tip="The identifier an edge node builds from a request." cta="Read more" href="/en/documentation/build/cache/cache-settings/">cache key</DocTooltip> decides what matches.
+The <DocTooltip client:visible headline="Cache key" tip="The identifier a data center builds from a request." cta="Read more" href="/en/documentation/build/cache/cache-settings/">cache key</DocTooltip> decides what matches.
 ```
 
 - `client:visible` is mandatory; without it the term renders and never opens.
@@ -335,7 +335,7 @@ import GlossaryFilter from '~/components/GlossaryFilter.astro'
 
 | Term | Definition |
 | --- | --- |
-| cache key | The identifier an edge node builds from a request to decide whether two requests match the same cached object. |
+| cache key | The identifier a data center builds from a request to decide whether two requests match the same cached object. |
 
 </GlossaryFilter>
 ```

src/content/docs/en/pages/style-guide/content/architecture.mdx

@@ -13,22 +13,23 @@ import DocItem from '@aziontech/webkit/doc-item'
 
 ## Purpose
 
-An architecture page shows how several products combine into one design. The reader wants to understand the shape of a solution before building it.
+An architecture page shows one Reference Architecture from the Use Case catalog: how Products and Platform Resources combine into one design. The reader wants to understand the shape of the design before building it.
 
 It applies the **explanation** base form, the same form as a [concept page](/en/documentation/style-guide/content/concept/). The difference is the subject: a concept page explains one thing, an architecture page explains how many things fit together.
 
 ## When to use
 
 Write an architecture page when:
 
-- A solution needs more than one product, and the relationship between them is the point.
+- A design needs more than one Product or Platform Resource, and the relationship between them is the point.
 - The reader must see the order of a request or a dataflow to understand the design.
 - A guide keeps redrawing the same system in prose.
 
 Do not write an architecture page when:
 
 - The subject is one product or one idea. Write a [concept page](/en/documentation/style-guide/content/concept/).
-- The reader wants to build the thing. Write a [multi-product guide](/en/documentation/style-guide/content/multi-product-guides/) and link it from here.
+- The reader wants to build the thing. Write the [use-case page](/en/documentation/style-guide/content/use-cases/) that builds it, or a [multi-product guide](/en/documentation/style-guide/content/multi-product-guides/), and link it from here.
+- The catalog has no entry for the design. Propose it to the Use Case catalog first; the page comes after the entry.
 - The design cannot be drawn. A design you cannot draw is one you do not yet understand well enough to publish.
 
 ## Register
@@ -37,14 +38,14 @@ Descriptive: 25 words per sentence, active voice, passive only when the actor is
 
 ## Structure
 
-The title names the design as a noun phrase: `Content delivery on a distributed network`. The opening paragraph states what problem the design solves and for whom.
+The title is the Reference Architecture name from the catalog, verbatim. That name is a noun phrase naming the system built, such as `Server-rendered headless CMS website`, never with a *Reference Architecture* suffix. The opening paragraph is the entry's Summary: what problem the design solves, and for whom. It names the Use Case the design implements, linked to the use-case page where one is published.
 
 **Required sections, in order**
 
 - **`## Architecture diagram`**: the diagram as a `mermaid` code fence, then a paragraph that reads it.
 - **`### Dataflow`**: a numbered walkthrough of what moves where, with six items at most.
-- **`## Components`**: what each part does and why it is there.
-- **`## Implementation`**: links to the how-tos, and only links.
+- **`## Components`**: one entry per Component of the catalog entry, with its role. Products go by name, Platform Resources lowercase as instances, and features and integrations labeled as the catalog labels them.
+- **`## Implementation`**: only links. The use-case page goes here when it builds this design, followed by the guides and Marketplace templates that implement all or part of it. A use-case page that builds a sibling design is linked from the opening paragraph, as the Use Case the architecture implements, and not here.
 - **`## Related resources`**: the closing section, a `DocItem` list, each row with its reason.
 
 ## Template
@@ -54,7 +55,7 @@ import FrameBox from '@aziontech/webkit/frame-box'
 import ItemList from '@aziontech/webkit/item-list'
 import DocItem from '@aziontech/webkit/doc-item'
 
-<What problem this design solves, and for whom.>
+<The entry's Summary: what problem this design solves, for whom, and which Use Case it implements.>
 
 ## Architecture diagram
 
@@ -78,7 +79,8 @@ flowchart LR
 
 ## Implementation
 
-- [<How-to that implements this design>](<guide URL>) - <why the reader follows it>.
+- [<Use-case page, only when it builds this design>](<page URL>) - <why the reader follows it>.
+- [<Guide or template that implements part of it>](<URL>) - <which part it implements>.
 
 ## Related resources
 
@@ -95,41 +97,43 @@ flowchart LR
 - **The diagram never stands alone.** The numbered dataflow carries the meaning, and it stays even when the diagram renders.
 - **Label every node and edge in words**, and never rely on color alone to carry a distinction.
 - **Name every component and say why it is there.** A list of product names is a parts list.
-- **Link the implementation, do not inline it.** Steps belong in a [multi-product guide](/en/documentation/style-guide/content/multi-product-guides/).
+- **Link the implementation, do not inline it.** Steps belong in the [use-case page](/en/documentation/style-guide/content/use-cases/) or a [multi-product guide](/en/documentation/style-guide/content/multi-product-guides/).
 - **Write only the sections you can confirm.** A required section whose content you cannot confirm with the team that owns the product is left out until you can, never filled with a guess.
+- **Report the permalink when the page ships**, so the catalog entry's Docs field can read Published.
 
 ## Examples
 
-- [Deploy Jamstack websites on a distributed network](/en/documentation/architectures/build-and-run-applications/deploy-jamstack-applications/): a diagram, a numbered dataflow, the components involved, and links out to the implementation.
+- [Deploy Jamstack websites](/en/documentation/architectures/build-and-run-applications/deploy-jamstack-applications/): the published page the catalog maps to *Git-driven static website*. It carries a diagram, a numbered dataflow, the components involved, and links out to the implementation.
 
-This trimmed excerpt shows the opening, the diagram section, and the dataflow:
+This trimmed excerpt shows the opening, the diagram section, and the dataflow of the *Git-driven static website* page. The catalog records that Reference Architecture under the Use Case *Build and run marketing websites*. No use-case page is published yet, so the Use Case is named without a link:
 
 ````mdx
-This design delivers a site's content from locations close to users. It reduces latency and the load on the origin infrastructure. Use it when your team delivers static-heavy sites and applications.
+A static website whose pages and content live in a Git repository. The Azion GitHub App builds the site on every push and deploys the output to Object Storage. An application serves the output through Cache, and a previous build can be redeployed to roll back. This design implements the Use Case *Build and run marketing websites*.
 
 ## Architecture diagram
 
 ```mermaid
 flowchart LR
-  Client -->|HTTP request| Node[Azion node]
-  Node --> Rules[Rules Engine]
-  Rules --> Cache[Cache layer]
-  Cache -->|Cache hit| Client
-  Cache -->|Cache miss| Origin[Origin server]
-  Origin --> Cache
+  Repo[Git repository] -->|push| App[Azion GitHub App]
+  App -->|build output| Bucket[Object Storage bucket]
+  Client -->|HTTP request| DC[Azion data center]
+  DC --> Cache[Cache]
+  Cache -->|cache hit| Client
+  Cache -->|cache miss| Bucket
+  Bucket --> Cache
 ```
 
-The diagram shows the path of a request and its response through an application on Azion's distributed network. A client request reaches a node on Azion's distributed network, where Rules Engine and the cache layer process it. Content that is not in the cache comes from the origin server, and the response returns to the client through the same node.
+The diagram carries two flows. The publish flow runs from the repository through the GitHub App to the bucket, and it moves only on a push. The request flow runs from the client to a data center on Azion's distributed infrastructure. There, Cache answers from its copy or reads the file from the bucket.
 
 ### Dataflow
 
-A request moves through the design in this order:
+Content moves through the design in this order:
 
-1. A client sends an HTTP or HTTPS request to a domain associated with an application.
-2. At the Azion node, Rules Engine processes the request. It applies cache policies and image optimization behaviors in the request phase.
-3. The cache layer evaluates the request. On a cache-key match, the node delivers the object from the cache.
-4. On a cache miss, the node forwards the request to the origin server. The origin responds, and the node caches the content.
-5. Before the response returns to the client, Rules Engine processes the response-phase policies. The node then delivers the content to the user.
+1. A push to the repository triggers the Azion GitHub App, which builds the site.
+2. The GitHub App deploys the build output to the Object Storage bucket.
+3. A client sends an HTTP or HTTPS request to the domain of the application that serves the bucket.
+4. In the data center, Cache answers the request from its copy of the file when it holds one.
+5. On a cache miss, the application reads the file from the bucket, and Cache stores it for the next request.
 ````
 
 ## Related

src/content/docs/en/pages/style-guide/content/changelog.mdx

@@ -37,7 +37,7 @@ An entry sits under a date heading and runs three to six short paragraphs, with
 **Required components**
 
 - **A date heading**: `## <Month> <day>, <year>`, newest first. Dates are allowed in changelogs and only in changelogs.
-- **The opening sentence**: `**<Product>** now <verb>s <capability>.`, plus the concrete detail: the flag, the field, or the default.
+- **The opening sentence**: `**<Product>** now <verb>s <what it now does>.`, plus the concrete detail: the flag, the field, or the default.
 - **What it means concretely**: what works without configuration now, or what behaves differently.
 - **Who is not affected**: existing configurations, earlier versions, accounts that did not opt in.
 - **The closing link**: `For more information, refer to [<the documenting page>](/en/documentation/.../).`
@@ -54,7 +54,7 @@ An entry sits under a date heading and runs three to six short paragraphs, with
 
 ### <Product> <version, when there is one>
 
-**<Product>** now <verb>s <capability>, <the concrete detail: the flag, field, or default>.
+**<Product>** now <verb>s <what it now does>, <the concrete detail: the flag, field, or default>.
 
 <What this means in practice: what works without configuration now, or what behaves differently.>
 
@@ -67,7 +67,7 @@ For more information, refer to [<the documenting page>](/en/documentation/.../).
 
 ## Rules
 
-- **Open with the product as the subject.** `**<Product>** now <verb>s <capability>.` Present tense, never `we`, never `Azion is excited to`.
+- **Open with the product as the subject.** `**<Product>** now <verb>s <what it now does>.` Present tense, never `we`, never `Azion is excited to`.
 - **State who is not affected.** A reader's first question about any change is whether it breaks them; answer it before they ask.
 - **Show migration or opt-in steps when the surface changed.** An API, CLI, or configuration change gets a code sample; two lines is enough.
 - **Close every entry with the documentation link.** An entry that documents the feature in full is a page filed in the wrong place.

src/content/docs/en/pages/style-guide/content/choose-a-content-type.mdx

@@ -32,11 +32,11 @@ A page kind is a base form plus a place in the [information architecture](/en/do
 | [Tutorial](/en/documentation/style-guide/content/tutorials/) | Tutorial | No | Teach the product by building a goal the author chose |
 | [How-to guide](/en/documentation/style-guide/content/how-to-guides/) | How-to | No | Complete one task the reader arrived with |
 | [Multi-product guide](/en/documentation/style-guide/content/multi-product-guides/) | How-to | No | Reach a goal that crosses products, on one recommended path |
-| [Use case](/en/documentation/style-guide/content/use-cases/) | How-to | No | Implement a business scenario end to end, as a spec an agent can follow |
+| [Use case](/en/documentation/style-guide/content/use-cases/) | How-to | No | Build a Use Case from the catalog end to end, as a spec an agent can follow |
 | [Troubleshooting](/en/documentation/style-guide/content/troubleshooting/) | How-to | No | From a symptom the reader sees to a fix |
 | [Reference](/en/documentation/style-guide/content/reference/) | Reference | No | Look up fields, values, defaults, and limits |
 | [Concept](/en/documentation/style-guide/content/concept/) | Explanation | No | Understand how something works and why it is built that way |
-| [Architecture](/en/documentation/style-guide/content/architecture/) | Explanation | No | How products combine into a design |
+| [Architecture](/en/documentation/style-guide/content/architecture/) | Explanation | No | One Reference Architecture from the catalog: how Products and Platform Resources combine into a design |
 | [Changelog](/en/documentation/style-guide/content/changelog/) | Record | No | Log notable changes, append-only |
 | [Glossary](/en/documentation/style-guide/content/glossary/) | Reference | Yes | Define the terms the product's documentation uses, in a filterable table |
 | [Navigation hub](/en/documentation/style-guide/content/navigation-hubs/) | None | No | Direct readers deeper. Links plus one sentence of orientation |
@@ -45,16 +45,17 @@ A page kind is a base form plus a place in the [information architecture](/en/do
 
 A slot is a position in a product section; a kind is the shape of a page. The [information architecture](/en/documentation/style-guide/content/information-architecture/) lists thirteen slots, and this catalog holds thirteen kinds. Equal length is a coincidence: the two lists do not map onto each other.
 
-Several slots share one kind. Limits, Examples, and Features and capabilities all hold reference pages, placed in different slots because readers reach them at different moments. Best practices and How it works both hold concept pages. One slot can also hold several kinds: Guides and tutorials holds a navigation hub, the how-to guides, and the tutorials. Adding a slot never adds a kind, and a page that fits no kind is a page whose content type is still undecided.
+Several slots share one kind. Limits, Examples, and Features all hold reference pages, placed in different slots because readers reach them at different moments. Best practices and How it works both hold concept pages. One slot can also hold several kinds: Guides and tutorials holds a navigation hub, the how-to guides, and the tutorials. Adding a slot never adds a kind, and a page that fits no kind is a page whose content type is still undecided.
 
 ## Kinds Azion does not use
 
 Some kinds common in other documentation sets are deliberately absent, because each dissolves into the catalog:
 
 - **FAQ**: a list of questions is a list of pages in disguise. Route each answer to its kind, and the question becomes a heading a search can find.
 - **Configuration**: examples of settings and values are reference content. The kind adds a second name for the same page.
-- **Design, implementation, and solution guides**: three names for content the catalog already holds. A goal that crosses products is a [multi-product guide](/en/documentation/style-guide/content/multi-product-guides/). A business scenario built end to end is a [use case](/en/documentation/style-guide/content/use-cases/). The reasoning behind a design is a [concept](/en/documentation/style-guide/content/concept/) or an [architecture](/en/documentation/style-guide/content/architecture/) page.
+- **Design, implementation, and solution guides**: three names for content the catalog already holds. A goal that crosses products is a [multi-product guide](/en/documentation/style-guide/content/multi-product-guides/). A Use Case from the catalog, built end to end, is a [use case](/en/documentation/style-guide/content/use-cases/). The reasoning behind a design is a [concept](/en/documentation/style-guide/content/concept/) or an [architecture](/en/documentation/style-guide/content/architecture/) page.
 - **Third-party integration guide**: a how-to guide that crosses a vendor's interface. The [third-party rules](/en/documentation/style-guide/content/how-to-guides/) cover it.
+- **Solution page**: a Solution lives on the website, not in the documentation. Here a Solution is the label of a Guides area and of an Architectures group. The pages are the use cases and architectures under it.
 - **API guidelines** are not covered by this guide yet.
 
 ## Separate tutorials from how-to guides
@@ -81,9 +82,9 @@ Both take the how-to base form and both cross products, so the split is worth st
 
 A multi-product guide starts from a technical goal. The reader knows what they want to build and needs the route across products. It ends when the task is done.
 
-A use case starts from a business scenario. The reader arrives with a situation, not a task. The page names the products the scenario needs, shows the architecture, configures it, and proves it works. It is written as a specification an agent can execute. That is why it carries a requirements table and a measurable outcome, which the multi-product guide does not.
+A use case starts from a catalog entry: a customer situation the Use Case catalog already names and places under its Solution. The reader arrives with a situation, not a task. The page names the products the scenario needs, shows the architecture, configures it, and proves it works. It is written as a specification an agent can execute. That is why it carries a requirements table and a measurable outcome, which the multi-product guide does not.
 
-The test: if you can state the goal without naming an industry or a business situation, it is a multi-product guide.
+The test runs in two steps. First match the goal to the Use Case catalog: an entry makes the page a use case, whatever the wording of the goal. With no entry, a goal the reader states without a customer situation is a multi-product guide. A customer situation the catalog should carry is a proposal for a new entry, not a page.
 
 ## Keep one form per page