docs: add complete GitW3 user guide

docs/docs/GitW3/_category_.json

@@ -0,0 +1,8 @@
+{
+ "label": "GitW3",
+ "position": 1.5,
+ "link": {
+ "type": "generated-index",
+ "description": "Sign in, create or port a W3DS platform, publish releases, apply for PPA, and register deployments with GitW3."
+ }
+}

docs/docs/GitW3/create-a-platform.md

@@ -0,0 +1,79 @@
+---
+sidebar_position: 3
+title: Create a new platform
+description: Create a repository, initial W3DS manifest, and permanent platform identity with GitW3.
+---
+
+# Create a new platform
+
+Use **Make a new platform** when the application does not already have a W3DS platform identity. GitW3 creates the repository and initial manifest, then provisions the permanent platform eName asynchronously.
+
+From the **+** menu, select **New repository**, then choose **Make a new platform**.
+
+![The GitW3 choice between making a new platform and porting an existing application.](/img/gitw3/choose-platform-path.png)
+
+## Step 1: Repository
+
+Choose the owner and describe where the code will live:
+
+1. Select your user or an organization as **Owner**.
+2. Decide whether the repository is private.
+3. Enter the human-facing **Display name**.
+4. Confirm the default branch, normally `main`.
+
+![Step one of the create-platform wizard, where the owner and display name are selected.](/img/gitw3/new-platform-repository.png)
+
+You do not choose a repository slug. GitW3 derives a URL-safe repository name and the initial stable `platformName` from the display name. If that name is already used under the owner, GitW3 adds a numeric suffix safely.
+
+The display name can change later. Treat `platformName` as the permanent machine-facing identity; GitW3 will not change it when the friendly name changes.
+
+## Step 2: Platform details
+
+Enter the information W3DS needs to describe the platform:
+
+- **Description:** a concise explanation of what the platform does;
+- **Application domains:** one or more domains from the W3DS ontology;
+- **Application URL:** the public URL, if the application is already deployed; and
+- **Logo URL:** an optional public image URL.
+
+![Step two of the create-platform wizard, with a description, W3DS domains, application URL, and logo URL.](/img/gitw3/new-platform-details.png)
+
+The version is controlled by Git releases, not entered in this form. The initial version is `0.1.0` until a stable semantic release becomes the repository's published version.
+
+You can leave the application URL empty while building. It is required before applying for PPA.
+
+## Step 3: AI setup
+
+Choose whether GitW3 should show the quick install for the W3DS coding-agent skill.
+
+![Step three of the create-platform wizard, offering the W3DS skill command for supported coding agents.](/img/gitw3/new-platform-ai-setup.png)
+
+The command works with supported agents including Codex, Claude Code, Cursor, Copilot, and Windsurf:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+Select **Create platform**. GitW3 creates:
+
+- the repository;
+- an initial README;
+- `.w3ds/platform.json`; and
+- the first commit on the default branch.
+
+It does not create or expose a reusable platform private key. The permanent platform identity and its eVault are provisioned automatically without an application or deployment key.
+
+## After creation
+
+The welcome page shows the permanent eName as soon as publication completes. Keep the page open or return to the **W3DS** tab later; provisioning continues in the background.
+
+Next:
+
+1. Clone the repository and push the application code.
+2. Open the **W3DS** tab and confirm the manifest and identity status.
+3. Add the public application URL when the deployment is reachable.
+4. Publish a stable semantic release such as `v0.1.0`.
+5. Apply for a PPA certificate for that exact version.
+6. Register a deployment from the **Deploy** tab.
+
+See [The platform manifest and W3DS workspace](./platform-manifest-and-workspace) for the generated file and editable fields.

docs/docs/GitW3/deploy-a-release.md

@@ -0,0 +1,99 @@
+---
+sidebar_position: 8
+title: Register a deployment
+description: Create and sign a verifiable W3DS deployment record for a PPA-certified release.
+---
+
+# Register a deployment
+
+The GitW3 **Deploy** tab registers a verifiable W3DS deployment identity for a published release. It binds the exact code version, deployment environment, connected deployer, and a public application key.
+
+:::important
+
+This flow does not upload or run the application. Deploy the code with your normal hosting provider or pipeline, then use the generated key in that server or runtime when PP-Auth integration is available.
+
+:::
+
+## Prerequisites
+
+Before starting, confirm:
+
+- the platform eName is ready;
+- a stable semantic release is published;
+- PPA has granted a certificate for that exact version;
+- you are signed in with the eID wallet that will act as the deployer; and
+- the W3DS deployment publisher is available.
+
+Every deployment belongs to the connected deployer's eName. It does not claim that the platform authors or release committers operated the deployment.
+
+## Step 1: Choose release
+
+Open **Deploy** and select a PPA-certified release. The release binds the version tag and exact commit to the stable platform eName. Uncertified releases remain unavailable.
+
+You can register additional versions later without replacing earlier records.
+
+## Step 2: Describe deployment
+
+Enter a human-friendly name such as `Singapore production`, then choose an environment:
+
+- Production
+- Staging
+- Development
+- Custom
+
+These values distinguish multiple deployments of the same release. They do not configure a hosting region, DNS record, or deployment pipeline.
+
+## Step 3: Bind an application key
+
+Choose one of two key paths:
+
+### Generate a deployment key
+
+This is recommended for a first deployment. GitW3 generates an ECDSA P-256 key pair in the browser and downloads `w3ds-deployment-key.json` immediately. The backup uses the `w3ds-deployment-key-v1` format and contains:
+
+- algorithm metadata for ECDSA P-256 with SHA-256;
+- the `z`-prefixed public key;
+- the base64-encoded PKCS#8 private key; and
+- a creation timestamp.
+
+Confirm that the file was downloaded and stored safely before continuing.
+
+### Use an existing public key
+
+Choose this path when your runtime or secret manager already controls a compatible W3DS P-256 key. Paste only the `z`-prefixed public key. Do not upload or paste the private key into GitW3.
+
+:::danger The private key is shown only through the download
+
+GitW3 receives the public key and cannot recover the private key. Never commit `w3ds-deployment-key.json`, paste it into chat, expose it through an API, or ship it in a browser or mobile bundle.
+
+:::
+
+Store the private file in the hosting provider's secret manager or a read-only server mount. Prefer an environment variable such as `W3DS_DEPLOYMENT_KEY_FILE` that points to the mounted file instead of putting key material in an environment variable.
+
+## Step 4: Review and sign
+
+Review the release, deployment name, environment, deployer identity, and key handling confirmation. GitW3 reserves two identities:
+
+- a **deployment eName** bound to the deployment's public key and connected deployer; and
+- a **software-version eName** bound to the stable platform eName, release version, and exact Git commit.
+
+Select **Create identities and continue to wallet**, then scan or open the eID wallet. One wallet signature covers both documents. Nothing is provisioned until the signature is verified.
+
+## Publication and server integration
+
+The deployment card progresses through publishing, waiting for W3DS, published, or needs-attention states. After publication it shows both eNames and a **Use AI to configure the server** helper.
+
+That generated prompt contains the verified public deployment context but not the private key. It asks a coding assistant to:
+
+- inspect the existing server runtime and deployment method;
+- add a server-only loader for `w3ds-deployment-key-v1`;
+- validate P-256/SHA-256 and ensure the private key derives the expected public key;
+- keep key loading unreachable from client code;
+- use a secret manager or read-only mount; and
+- leave a narrow PP-Auth integration boundary without inventing an unpublished SDK or protocol.
+
+Keep the downloaded private-key file local when using that prompt. PP-Auth SDK integration is marked as coming soon in GitW3; do not invent a package name, endpoint, token format, or wire protocol.
+
+## Rotation and recovery
+
+If the private key is lost, GitW3 cannot restore it. Register a new deployment identity and update the server secret through a controlled rollout. Keep the old secret available only for the rollback window, verify the new public-key match at startup, then revoke or destroy the old secret according to your hosting policy.

docs/docs/GitW3/overview.md

@@ -0,0 +1,70 @@
+---
+sidebar_position: 1
+title: GitW3 overview
+description: Start here to understand GitW3 repositories, W3DS identities, releases, certification, and deployment records.
+---
+
+# GitW3 overview
+
+[GitW3](https://git.w3ds.metastate.foundation) is the W3DS-aware Git forge. It hosts source code and normal collaborative Git workflows, while connecting a platform repository to its permanent W3DS identity, published versions, PPA certificates, and verifiable deployment records.
+
+GitW3 is built around one rule: the repository is the source of truth for the platform metadata that W3DS publishes. The metadata lives beside the code in `.w3ds/platform.json`, and changes made from the GitW3 **W3DS** tab become ordinary commits on the default branch.
+
+## What GitW3 manages
+
+| Item | Meaning | Where you work with it |
+| --- | --- | --- |
+| Repository | Source code, issues, pull requests, tags, and releases | The regular repository tabs and Git |
+| Platform manifest | Version-controlled W3DS metadata | `.w3ds/platform.json` and the **W3DS** tab |
+| Platform eName | The permanent identity of the platform across releases | Provisioned automatically and shown on the **W3DS** tab |
+| Version eName | The identity of one exact released version | Derived from a stable Git release |
+| PPA certificate | Approval for one exact platform version | Apply and follow the review from the **W3DS** tab |
+| Deployment eName | A verifiable record of one running deployment | Created from the **Deploy** tab |
+
+The platform eName remains stable when the code, release, or deployment changes. Each released software version and each deployment receives its own identity so that W3DS records can refer to an exact artifact or running instance.
+
+:::important GitW3 records deployments; it does not host them
+
+The **Deploy** flow creates W3DS identities and attestations. Continue using your normal hosting provider or deployment pipeline to run the application.
+
+:::
+
+## The normal platform lifecycle
+
+```mermaid
+flowchart LR
+ A[Sign in with W3DS] --> B[Create or port a repository]
+ B --> C[Platform manifest committed]
+ C --> D[Permanent platform eName provisioned]
+ D --> E[Publish a stable release]
+ E --> F[Sign and submit PPA application]
+ F --> G[PPA certificate granted]
+ G --> H[Register and sign a deployment]
+```
+
+Identity and profile publication happen asynchronously. Git pushes and repository creation do not wait synchronously for every W3DS service. The status shown on the **W3DS** tab updates as the publisher completes or retries the work.
+
+## Choose the right starting path
+
+- **Make a new platform** creates a repository, an initial README, and `.w3ds/platform.json`. Use it when the application does not already have a W3DS identity.
+- **Port an existing app** creates an empty destination first. You then move the existing Git history and W3DS integration, transfer an existing eName if there is one, and explicitly activate the public cutover.
+- A regular code import is not the same as porting a W3DS platform. Use the guided port flow when an existing platform identity must remain intact.
+
+Continue with [Sign in and manage your account](./sign-in-and-account), [Create a new platform](./create-a-platform), or [Port an existing application](./port-an-existing-application).
+
+## Before you begin
+
+You need:
+
+- an eID wallet with a W3DS identity;
+- Git installed locally if you will clone or push code;
+- an SSH key or a GitW3 personal access token for command-line Git authentication; and
+- repository owner or organization permissions for actions such as PPA submission and migration activation.
+
+For application integration work, GitW3 can give a supported coding agent the current W3DS skill:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+The skill helps the agent use current protocol concepts and ontology identifiers. It does not replace review, tests, or secret handling.

docs/docs/GitW3/platform-manifest-and-workspace.md

@@ -0,0 +1,94 @@
+---
+sidebar_position: 6
+title: Platform manifest and W3DS workspace
+description: Understand .w3ds/platform.json, asynchronous publication, visibility, and the repository W3DS tab.
+---
+
+# Platform manifest and W3DS workspace
+
+Every GitW3 platform repository owns a manifest at `.w3ds/platform.json`. It is version-controlled platform metadata and the source from which GitW3 publishes the platform profile to W3DS.
+
+## Manifest shape
+
+A newly created platform starts with the following core fields:
+
+```json
+{
+ "schemaVersion": 1,
+ "platformName": "example-platform",
+ "displayName": "Example Platform",
+ "description": "A short description of the platform.",
+ "version": "0.1.0",
+ "ename": null,
+ "url": "https://example.invalid",
+ "logoUrl": "https://example.invalid/logo.png",
+ "domains": ["productivity", "work"],
+ "inSubmission": false,
+ "submissionVersion": "",
+ "isDraft": true
+}
+```
+
+Use real W3DS ontology domain identifiers from the GitW3 selector. The values above are illustrative.
+
+## Who controls each field
+
+| Field | Control and behavior |
+| --- | --- |
+| `schemaVersion` | Manifest format version. Do not change it without a supported schema migration. |
+| `platformName` | Stable machine-facing platform slug derived at creation. Immutable after identity creation. |
+| `displayName` | Human-facing name. Editable by permitted repository users. |
+| `description` | Human-facing platform description. |
+| `version` | Synchronized from the latest stable semantic GitW3 release; do not manually bump it. |
+| `ename` | Permanent platform eName. Initially `null`, then written by the publisher or preserved by the port flow. Immutable once assigned. |
+| `url` | Public application URL. Required for PPA submission. |
+| `logoUrl` | Optional public logo URL. |
+| `domains` | One or more supported W3DS application-domain identifiers. |
+| `inSubmission` | Whether the current release statement is in the PPA review flow. Managed by the signed application workflow. |
+| `submissionVersion` | Version associated with the current signed PPA submission. |
+| `isDraft` | Controls whether the synchronized platform profile is hidden from the public marketplace. |
+
+Migration and PPA workflows can add proof fields. Never fabricate, copy between platforms, or hand-edit cryptographic proof material.
+
+## The W3DS workspace
+
+Open a platform repository and select **W3DS**. The page is organized around the platform lifecycle:
+
+1. **Live publication status** reports the publisher's current state and latest result.
+2. **What happens next** tracks manifest, permanent identity, application URL, and stable release readiness.
+3. **Marketplace visibility** switches the profile between draft and published.
+4. **Platform details** edits the display name, description, domains, application URL, and logo URL.
+5. **PPA certificate** shows the requirement checklist, signed application, review conversation, and current decision.
+
+Repository or organization permissions control who may edit details, change visibility, apply for PPA, or activate a migration. Read-only visitors see the manifest-backed values without the edit controls.
+
+## Saving changes
+
+Saving through the W3DS workspace creates a normal commit on the default branch. GitW3 checks the last observed commit so it does not silently overwrite a newer manifest change.
+
+For changes made locally:
+
+1. Pull the latest default branch.
+2. Edit only supported, non-managed fields.
+3. Validate the JSON and domain identifiers.
+4. Commit and push normally.
+5. Open the **W3DS** tab and watch publication status.
+
+Do not manually change `platformName`, an assigned `ename`, release-controlled `version`, or signed proof fields.
+
+## Identity and publication are asynchronous
+
+After the initial manifest reaches the default branch, GitW3's publisher:
+
+- reserves and publishes the permanent platform eName;
+- provisions the platform eVault without an application key;
+- writes the assigned eName back to the manifest; and
+- synchronizes the platform profile and its visibility.
+
+Repository creation and Git pushes remain available while this happens. Temporary W3DS failures are retried; refresh the **W3DS** tab to see the current state. Repository administrators can see a detailed last error when intervention is required.
+
+The platform eName gets the platform eVault. Version eNames are Registry records for exact releases and do not create additional eVaults.
+
+## Draft versus published
+
+New platforms begin as drafts. A synchronized draft profile is hidden from the marketplace but still belongs to the repository. Use **Publish platform** in the W3DS workspace when the profile is ready to be discoverable; use **Make draft** to hide it again without deleting its stable identity.

docs/docs/GitW3/_category_.json

@@ -0,0 +1,8 @@
+{
+ "label": "GitW3",
+ "position": 1.5,
+ "link": {
+ "type": "generated-index",
+ "description": "Sign in, create or port a W3DS platform, publish releases, apply for PPA, and register deployments with GitW3."
+ }
+}

docs/docs/GitW3/create-a-platform.md

@@ -0,0 +1,79 @@
+---
+sidebar_position: 3
+title: Create a new platform
+description: Create a repository, initial W3DS manifest, and permanent platform identity with GitW3.
+---
+
+# Create a new platform
+
+Use **Make a new platform** when the application does not already have a W3DS platform identity. GitW3 creates the repository and initial manifest, then provisions the permanent platform eName asynchronously.
+
+From the **+** menu, select **New repository**, then choose **Make a new platform**.
+
+![The GitW3 choice between making a new platform and porting an existing application.](/img/gitw3/choose-platform-path.png)
+
+## Step 1: Repository
+
+Choose the owner and describe where the code will live:
+
+1. Select your user or an organization as **Owner**.
+2. Decide whether the repository is private.
+3. Enter the human-facing **Display name**.
+4. Confirm the default branch, normally `main`.
+
+![Step one of the create-platform wizard, where the owner and display name are selected.](/img/gitw3/new-platform-repository.png)
+
+You do not choose a repository slug. GitW3 derives a URL-safe repository name and the initial stable `platformName` from the display name. If that name is already used under the owner, GitW3 adds a numeric suffix safely.
+
+The display name can change later. Treat `platformName` as the permanent machine-facing identity; GitW3 will not change it when the friendly name changes.
+
+## Step 2: Platform details
+
+Enter the information W3DS needs to describe the platform:
+
+- **Description:** a concise explanation of what the platform does;
+- **Application domains:** one or more domains from the W3DS ontology;
+- **Application URL:** the public URL, if the application is already deployed; and
+- **Logo URL:** an optional public image URL.
+
+![Step two of the create-platform wizard, with a description, W3DS domains, application URL, and logo URL.](/img/gitw3/new-platform-details.png)
+
+The version is controlled by Git releases, not entered in this form. The initial version is `0.1.0` until a stable semantic release becomes the repository's published version.
+
+You can leave the application URL empty while building. It is required before applying for PPA.
+
+## Step 3: AI setup
+
+Choose whether GitW3 should show the quick install for the W3DS coding-agent skill.
+
+![Step three of the create-platform wizard, offering the W3DS skill command for supported coding agents.](/img/gitw3/new-platform-ai-setup.png)
+
+The command works with supported agents including Codex, Claude Code, Cursor, Copilot, and Windsurf:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+Select **Create platform**. GitW3 creates:
+
+- the repository;
+- an initial README;
+- `.w3ds/platform.json`; and
+- the first commit on the default branch.
+
+It does not create or expose a reusable platform private key. The permanent platform identity and its eVault are provisioned automatically without an application or deployment key.
+
+## After creation
+
+The welcome page shows the permanent eName as soon as publication completes. Keep the page open or return to the **W3DS** tab later; provisioning continues in the background.
+
+Next:
+
+1. Clone the repository and push the application code.
+2. Open the **W3DS** tab and confirm the manifest and identity status.
+3. Add the public application URL when the deployment is reachable.
+4. Publish a stable semantic release such as `v0.1.0`.
+5. Apply for a PPA certificate for that exact version.
+6. Register a deployment from the **Deploy** tab.
+
+See [The platform manifest and W3DS workspace](./platform-manifest-and-workspace) for the generated file and editable fields.

docs/docs/GitW3/deploy-a-release.md

@@ -0,0 +1,99 @@
+---
+sidebar_position: 8
+title: Register a deployment
+description: Create and sign a verifiable W3DS deployment record for a PPA-certified release.
+---
+
+# Register a deployment
+
+The GitW3 **Deploy** tab registers a verifiable W3DS deployment identity for a published release. It binds the exact code version, deployment environment, connected deployer, and a public application key.
+
+:::important
+
+This flow does not upload or run the application. Deploy the code with your normal hosting provider or pipeline, then use the generated key in that server or runtime when PP-Auth integration is available.
+
+:::
+
+## Prerequisites
+
+Before starting, confirm:
+
+- the platform eName is ready;
+- a stable semantic release is published;
+- PPA has granted a certificate for that exact version;
+- you are signed in with the eID wallet that will act as the deployer; and
+- the W3DS deployment publisher is available.
+
+Every deployment belongs to the connected deployer's eName. It does not claim that the platform authors or release committers operated the deployment.
+
+## Step 1: Choose release
+
+Open **Deploy** and select a PPA-certified release. The release binds the version tag and exact commit to the stable platform eName. Uncertified releases remain unavailable.
+
+You can register additional versions later without replacing earlier records.
+
+## Step 2: Describe deployment
+
+Enter a human-friendly name such as `Singapore production`, then choose an environment:
+
+- Production
+- Staging
+- Development
+- Custom
+
+These values distinguish multiple deployments of the same release. They do not configure a hosting region, DNS record, or deployment pipeline.
+
+## Step 3: Bind an application key
+
+Choose one of two key paths:
+
+### Generate a deployment key
+
+This is recommended for a first deployment. GitW3 generates an ECDSA P-256 key pair in the browser and downloads `w3ds-deployment-key.json` immediately. The backup uses the `w3ds-deployment-key-v1` format and contains:
+
+- algorithm metadata for ECDSA P-256 with SHA-256;
+- the `z`-prefixed public key;
+- the base64-encoded PKCS#8 private key; and
+- a creation timestamp.
+
+Confirm that the file was downloaded and stored safely before continuing.
+
+### Use an existing public key
+
+Choose this path when your runtime or secret manager already controls a compatible W3DS P-256 key. Paste only the `z`-prefixed public key. Do not upload or paste the private key into GitW3.
+
+:::danger The private key is shown only through the download
+
+GitW3 receives the public key and cannot recover the private key. Never commit `w3ds-deployment-key.json`, paste it into chat, expose it through an API, or ship it in a browser or mobile bundle.
+
+:::
+
+Store the private file in the hosting provider's secret manager or a read-only server mount. Prefer an environment variable such as `W3DS_DEPLOYMENT_KEY_FILE` that points to the mounted file instead of putting key material in an environment variable.
+
+## Step 4: Review and sign
+
+Review the release, deployment name, environment, deployer identity, and key handling confirmation. GitW3 reserves two identities:
+
+- a **deployment eName** bound to the deployment's public key and connected deployer; and
+- a **software-version eName** bound to the stable platform eName, release version, and exact Git commit.
+
+Select **Create identities and continue to wallet**, then scan or open the eID wallet. One wallet signature covers both documents. Nothing is provisioned until the signature is verified.
+
+## Publication and server integration
+
+The deployment card progresses through publishing, waiting for W3DS, published, or needs-attention states. After publication it shows both eNames and a **Use AI to configure the server** helper.
+
+That generated prompt contains the verified public deployment context but not the private key. It asks a coding assistant to:
+
+- inspect the existing server runtime and deployment method;
+- add a server-only loader for `w3ds-deployment-key-v1`;
+- validate P-256/SHA-256 and ensure the private key derives the expected public key;
+- keep key loading unreachable from client code;
+- use a secret manager or read-only mount; and
+- leave a narrow PP-Auth integration boundary without inventing an unpublished SDK or protocol.
+
+Keep the downloaded private-key file local when using that prompt. PP-Auth SDK integration is marked as coming soon in GitW3; do not invent a package name, endpoint, token format, or wire protocol.
+
+## Rotation and recovery
+
+If the private key is lost, GitW3 cannot restore it. Register a new deployment identity and update the server secret through a controlled rollout. Keep the old secret available only for the rollback window, verify the new public-key match at startup, then revoke or destroy the old secret according to your hosting policy.

docs/docs/GitW3/overview.md

@@ -0,0 +1,70 @@
+---
+sidebar_position: 1
+title: GitW3 overview
+description: Start here to understand GitW3 repositories, W3DS identities, releases, certification, and deployment records.
+---
+
+# GitW3 overview
+
+[GitW3](https://git.w3ds.metastate.foundation) is the W3DS-aware Git forge. It hosts source code and normal collaborative Git workflows, while connecting a platform repository to its permanent W3DS identity, published versions, PPA certificates, and verifiable deployment records.
+
+GitW3 is built around one rule: the repository is the source of truth for the platform metadata that W3DS publishes. The metadata lives beside the code in `.w3ds/platform.json`, and changes made from the GitW3 **W3DS** tab become ordinary commits on the default branch.
+
+## What GitW3 manages
+
+| Item | Meaning | Where you work with it |
+| --- | --- | --- |
+| Repository | Source code, issues, pull requests, tags, and releases | The regular repository tabs and Git |
+| Platform manifest | Version-controlled W3DS metadata | `.w3ds/platform.json` and the **W3DS** tab |
+| Platform eName | The permanent identity of the platform across releases | Provisioned automatically and shown on the **W3DS** tab |
+| Version eName | The identity of one exact released version | Derived from a stable Git release |
+| PPA certificate | Approval for one exact platform version | Apply and follow the review from the **W3DS** tab |
+| Deployment eName | A verifiable record of one running deployment | Created from the **Deploy** tab |
+
+The platform eName remains stable when the code, release, or deployment changes. Each released software version and each deployment receives its own identity so that W3DS records can refer to an exact artifact or running instance.
+
+:::important GitW3 records deployments; it does not host them
+
+The **Deploy** flow creates W3DS identities and attestations. Continue using your normal hosting provider or deployment pipeline to run the application.
+
+:::
+
+## The normal platform lifecycle
+
+```mermaid
+flowchart LR
+ A[Sign in with W3DS] --> B[Create or port a repository]
+ B --> C[Platform manifest committed]
+ C --> D[Permanent platform eName provisioned]
+ D --> E[Publish a stable release]
+ E --> F[Sign and submit PPA application]
+ F --> G[PPA certificate granted]
+ G --> H[Register and sign a deployment]
+```
+
+Identity and profile publication happen asynchronously. Git pushes and repository creation do not wait synchronously for every W3DS service. The status shown on the **W3DS** tab updates as the publisher completes or retries the work.
+
+## Choose the right starting path
+
+- **Make a new platform** creates a repository, an initial README, and `.w3ds/platform.json`. Use it when the application does not already have a W3DS identity.
+- **Port an existing app** creates an empty destination first. You then move the existing Git history and W3DS integration, transfer an existing eName if there is one, and explicitly activate the public cutover.
+- A regular code import is not the same as porting a W3DS platform. Use the guided port flow when an existing platform identity must remain intact.
+
+Continue with [Sign in and manage your account](./sign-in-and-account), [Create a new platform](./create-a-platform), or [Port an existing application](./port-an-existing-application).
+
+## Before you begin
+
+You need:
+
+- an eID wallet with a W3DS identity;
+- Git installed locally if you will clone or push code;
+- an SSH key or a GitW3 personal access token for command-line Git authentication; and
+- repository owner or organization permissions for actions such as PPA submission and migration activation.
+
+For application integration work, GitW3 can give a supported coding agent the current W3DS skill:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+The skill helps the agent use current protocol concepts and ontology identifiers. It does not replace review, tests, or secret handling.

docs/docs/GitW3/platform-manifest-and-workspace.md

@@ -0,0 +1,94 @@
+---
+sidebar_position: 6
+title: Platform manifest and W3DS workspace
+description: Understand .w3ds/platform.json, asynchronous publication, visibility, and the repository W3DS tab.
+---
+
+# Platform manifest and W3DS workspace
+
+Every GitW3 platform repository owns a manifest at `.w3ds/platform.json`. It is version-controlled platform metadata and the source from which GitW3 publishes the platform profile to W3DS.
+
+## Manifest shape
+
+A newly created platform starts with the following core fields:
+
+```json
+{
+ "schemaVersion": 1,
+ "platformName": "example-platform",
+ "displayName": "Example Platform",
+ "description": "A short description of the platform.",
+ "version": "0.1.0",
+ "ename": null,
+ "url": "https://example.invalid",
+ "logoUrl": "https://example.invalid/logo.png",
+ "domains": ["productivity", "work"],
+ "inSubmission": false,
+ "submissionVersion": "",
+ "isDraft": true
+}
+```
+
+Use real W3DS ontology domain identifiers from the GitW3 selector. The values above are illustrative.
+
+## Who controls each field
+
+| Field | Control and behavior |
+| --- | --- |
+| `schemaVersion` | Manifest format version. Do not change it without a supported schema migration. |
+| `platformName` | Stable machine-facing platform slug derived at creation. Immutable after identity creation. |
+| `displayName` | Human-facing name. Editable by permitted repository users. |
+| `description` | Human-facing platform description. |
+| `version` | Synchronized from the latest stable semantic GitW3 release; do not manually bump it. |
+| `ename` | Permanent platform eName. Initially `null`, then written by the publisher or preserved by the port flow. Immutable once assigned. |
+| `url` | Public application URL. Required for PPA submission. |
+| `logoUrl` | Optional public logo URL. |
+| `domains` | One or more supported W3DS application-domain identifiers. |
+| `inSubmission` | Whether the current release statement is in the PPA review flow. Managed by the signed application workflow. |
+| `submissionVersion` | Version associated with the current signed PPA submission. |
+| `isDraft` | Controls whether the synchronized platform profile is hidden from the public marketplace. |
+
+Migration and PPA workflows can add proof fields. Never fabricate, copy between platforms, or hand-edit cryptographic proof material.
+
+## The W3DS workspace
+
+Open a platform repository and select **W3DS**. The page is organized around the platform lifecycle:
+
+1. **Live publication status** reports the publisher's current state and latest result.
+2. **What happens next** tracks manifest, permanent identity, application URL, and stable release readiness.
+3. **Marketplace visibility** switches the profile between draft and published.
+4. **Platform details** edits the display name, description, domains, application URL, and logo URL.
+5. **PPA certificate** shows the requirement checklist, signed application, review conversation, and current decision.
+
+Repository or organization permissions control who may edit details, change visibility, apply for PPA, or activate a migration. Read-only visitors see the manifest-backed values without the edit controls.
+
+## Saving changes
+
+Saving through the W3DS workspace creates a normal commit on the default branch. GitW3 checks the last observed commit so it does not silently overwrite a newer manifest change.
+
+For changes made locally:
+
+1. Pull the latest default branch.
+2. Edit only supported, non-managed fields.
+3. Validate the JSON and domain identifiers.
+4. Commit and push normally.
+5. Open the **W3DS** tab and watch publication status.
+
+Do not manually change `platformName`, an assigned `ename`, release-controlled `version`, or signed proof fields.
+
+## Identity and publication are asynchronous
+
+After the initial manifest reaches the default branch, GitW3's publisher:
+
+- reserves and publishes the permanent platform eName;
+- provisions the platform eVault without an application key;
+- writes the assigned eName back to the manifest; and
+- synchronizes the platform profile and its visibility.
+
+Repository creation and Git pushes remain available while this happens. Temporary W3DS failures are retried; refresh the **W3DS** tab to see the current state. Repository administrators can see a detailed last error when intervention is required.
+
+The platform eName gets the platform eVault. Version eNames are Registry records for exact releases and do not create additional eVaults.
+
+## Draft versus published
+
+New platforms begin as drafts. A synchronized draft profile is hidden from the marketplace but still belongs to the repository. Use **Publish platform** in the W3DS workspace when the profile is ready to be discoverable; use **Make draft** to hide it again without deleting its stable identity.

docs/docs/GitW3/_category_.json

@@ -0,0 +1,8 @@
+{
+ "label": "GitW3",
+ "position": 1.5,
+ "link": {
+ "type": "generated-index",
+ "description": "Sign in, create or port a W3DS platform, publish releases, apply for PPA, and register deployments with GitW3."
+ }
+}

docs/docs/GitW3/create-a-platform.md

@@ -0,0 +1,79 @@
+---
+sidebar_position: 3
+title: Create a new platform
+description: Create a repository, initial W3DS manifest, and permanent platform identity with GitW3.
+---
+
+# Create a new platform
+
+Use **Make a new platform** when the application does not already have a W3DS platform identity. GitW3 creates the repository and initial manifest, then provisions the permanent platform eName asynchronously.
+
+From the **+** menu, select **New repository**, then choose **Make a new platform**.
+
+![The GitW3 choice between making a new platform and porting an existing application.](/img/gitw3/choose-platform-path.png)
+
+## Step 1: Repository
+
+Choose the owner and describe where the code will live:
+
+1. Select your user or an organization as **Owner**.
+2. Decide whether the repository is private.
+3. Enter the human-facing **Display name**.
+4. Confirm the default branch, normally `main`.
+
+![Step one of the create-platform wizard, where the owner and display name are selected.](/img/gitw3/new-platform-repository.png)
+
+You do not choose a repository slug. GitW3 derives a URL-safe repository name and the initial stable `platformName` from the display name. If that name is already used under the owner, GitW3 adds a numeric suffix safely.
+
+The display name can change later. Treat `platformName` as the permanent machine-facing identity; GitW3 will not change it when the friendly name changes.
+
+## Step 2: Platform details
+
+Enter the information W3DS needs to describe the platform:
+
+- **Description:** a concise explanation of what the platform does;
+- **Application domains:** one or more domains from the W3DS ontology;
+- **Application URL:** the public URL, if the application is already deployed; and
+- **Logo URL:** an optional public image URL.
+
+![Step two of the create-platform wizard, with a description, W3DS domains, application URL, and logo URL.](/img/gitw3/new-platform-details.png)
+
+The version is controlled by Git releases, not entered in this form. The initial version is `0.1.0` until a stable semantic release becomes the repository's published version.
+
+You can leave the application URL empty while building. It is required before applying for PPA.
+
+## Step 3: AI setup
+
+Choose whether GitW3 should show the quick install for the W3DS coding-agent skill.
+
+![Step three of the create-platform wizard, offering the W3DS skill command for supported coding agents.](/img/gitw3/new-platform-ai-setup.png)
+
+The command works with supported agents including Codex, Claude Code, Cursor, Copilot, and Windsurf:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+Select **Create platform**. GitW3 creates:
+
+- the repository;
+- an initial README;
+- `.w3ds/platform.json`; and
+- the first commit on the default branch.
+
+It does not create or expose a reusable platform private key. The permanent platform identity and its eVault are provisioned automatically without an application or deployment key.
+
+## After creation
+
+The welcome page shows the permanent eName as soon as publication completes. Keep the page open or return to the **W3DS** tab later; provisioning continues in the background.
+
+Next:
+
+1. Clone the repository and push the application code.
+2. Open the **W3DS** tab and confirm the manifest and identity status.
+3. Add the public application URL when the deployment is reachable.
+4. Publish a stable semantic release such as `v0.1.0`.
+5. Apply for a PPA certificate for that exact version.
+6. Register a deployment from the **Deploy** tab.
+
+See [The platform manifest and W3DS workspace](./platform-manifest-and-workspace) for the generated file and editable fields.

docs/docs/GitW3/deploy-a-release.md

@@ -0,0 +1,99 @@
+---
+sidebar_position: 8
+title: Register a deployment
+description: Create and sign a verifiable W3DS deployment record for a PPA-certified release.
+---
+
+# Register a deployment
+
+The GitW3 **Deploy** tab registers a verifiable W3DS deployment identity for a published release. It binds the exact code version, deployment environment, connected deployer, and a public application key.
+
+:::important
+
+This flow does not upload or run the application. Deploy the code with your normal hosting provider or pipeline, then use the generated key in that server or runtime when PP-Auth integration is available.
+
+:::
+
+## Prerequisites
+
+Before starting, confirm:
+
+- the platform eName is ready;
+- a stable semantic release is published;
+- PPA has granted a certificate for that exact version;
+- you are signed in with the eID wallet that will act as the deployer; and
+- the W3DS deployment publisher is available.
+
+Every deployment belongs to the connected deployer's eName. It does not claim that the platform authors or release committers operated the deployment.
+
+## Step 1: Choose release
+
+Open **Deploy** and select a PPA-certified release. The release binds the version tag and exact commit to the stable platform eName. Uncertified releases remain unavailable.
+
+You can register additional versions later without replacing earlier records.
+
+## Step 2: Describe deployment
+
+Enter a human-friendly name such as `Singapore production`, then choose an environment:
+
+- Production
+- Staging
+- Development
+- Custom
+
+These values distinguish multiple deployments of the same release. They do not configure a hosting region, DNS record, or deployment pipeline.
+
+## Step 3: Bind an application key
+
+Choose one of two key paths:
+
+### Generate a deployment key
+
+This is recommended for a first deployment. GitW3 generates an ECDSA P-256 key pair in the browser and downloads `w3ds-deployment-key.json` immediately. The backup uses the `w3ds-deployment-key-v1` format and contains:
+
+- algorithm metadata for ECDSA P-256 with SHA-256;
+- the `z`-prefixed public key;
+- the base64-encoded PKCS#8 private key; and
+- a creation timestamp.
+
+Confirm that the file was downloaded and stored safely before continuing.
+
+### Use an existing public key
+
+Choose this path when your runtime or secret manager already controls a compatible W3DS P-256 key. Paste only the `z`-prefixed public key. Do not upload or paste the private key into GitW3.
+
+:::danger The private key is shown only through the download
+
+GitW3 receives the public key and cannot recover the private key. Never commit `w3ds-deployment-key.json`, paste it into chat, expose it through an API, or ship it in a browser or mobile bundle.
+
+:::
+
+Store the private file in the hosting provider's secret manager or a read-only server mount. Prefer an environment variable such as `W3DS_DEPLOYMENT_KEY_FILE` that points to the mounted file instead of putting key material in an environment variable.
+
+## Step 4: Review and sign
+
+Review the release, deployment name, environment, deployer identity, and key handling confirmation. GitW3 reserves two identities:
+
+- a **deployment eName** bound to the deployment's public key and connected deployer; and
+- a **software-version eName** bound to the stable platform eName, release version, and exact Git commit.
+
+Select **Create identities and continue to wallet**, then scan or open the eID wallet. One wallet signature covers both documents. Nothing is provisioned until the signature is verified.
+
+## Publication and server integration
+
+The deployment card progresses through publishing, waiting for W3DS, published, or needs-attention states. After publication it shows both eNames and a **Use AI to configure the server** helper.
+
+That generated prompt contains the verified public deployment context but not the private key. It asks a coding assistant to:
+
+- inspect the existing server runtime and deployment method;
+- add a server-only loader for `w3ds-deployment-key-v1`;
+- validate P-256/SHA-256 and ensure the private key derives the expected public key;
+- keep key loading unreachable from client code;
+- use a secret manager or read-only mount; and
+- leave a narrow PP-Auth integration boundary without inventing an unpublished SDK or protocol.
+
+Keep the downloaded private-key file local when using that prompt. PP-Auth SDK integration is marked as coming soon in GitW3; do not invent a package name, endpoint, token format, or wire protocol.
+
+## Rotation and recovery
+
+If the private key is lost, GitW3 cannot restore it. Register a new deployment identity and update the server secret through a controlled rollout. Keep the old secret available only for the rollback window, verify the new public-key match at startup, then revoke or destroy the old secret according to your hosting policy.

docs/docs/GitW3/overview.md

@@ -0,0 +1,70 @@
+---
+sidebar_position: 1
+title: GitW3 overview
+description: Start here to understand GitW3 repositories, W3DS identities, releases, certification, and deployment records.
+---
+
+# GitW3 overview
+
+[GitW3](https://git.w3ds.metastate.foundation) is the W3DS-aware Git forge. It hosts source code and normal collaborative Git workflows, while connecting a platform repository to its permanent W3DS identity, published versions, PPA certificates, and verifiable deployment records.
+
+GitW3 is built around one rule: the repository is the source of truth for the platform metadata that W3DS publishes. The metadata lives beside the code in `.w3ds/platform.json`, and changes made from the GitW3 **W3DS** tab become ordinary commits on the default branch.
+
+## What GitW3 manages
+
+| Item | Meaning | Where you work with it |
+| --- | --- | --- |
+| Repository | Source code, issues, pull requests, tags, and releases | The regular repository tabs and Git |
+| Platform manifest | Version-controlled W3DS metadata | `.w3ds/platform.json` and the **W3DS** tab |
+| Platform eName | The permanent identity of the platform across releases | Provisioned automatically and shown on the **W3DS** tab |
+| Version eName | The identity of one exact released version | Derived from a stable Git release |
+| PPA certificate | Approval for one exact platform version | Apply and follow the review from the **W3DS** tab |
+| Deployment eName | A verifiable record of one running deployment | Created from the **Deploy** tab |
+
+The platform eName remains stable when the code, release, or deployment changes. Each released software version and each deployment receives its own identity so that W3DS records can refer to an exact artifact or running instance.
+
+:::important GitW3 records deployments; it does not host them
+
+The **Deploy** flow creates W3DS identities and attestations. Continue using your normal hosting provider or deployment pipeline to run the application.
+
+:::
+
+## The normal platform lifecycle
+
+```mermaid
+flowchart LR
+ A[Sign in with W3DS] --> B[Create or port a repository]
+ B --> C[Platform manifest committed]
+ C --> D[Permanent platform eName provisioned]
+ D --> E[Publish a stable release]
+ E --> F[Sign and submit PPA application]
+ F --> G[PPA certificate granted]
+ G --> H[Register and sign a deployment]
+```
+
+Identity and profile publication happen asynchronously. Git pushes and repository creation do not wait synchronously for every W3DS service. The status shown on the **W3DS** tab updates as the publisher completes or retries the work.
+
+## Choose the right starting path
+
+- **Make a new platform** creates a repository, an initial README, and `.w3ds/platform.json`. Use it when the application does not already have a W3DS identity.
+- **Port an existing app** creates an empty destination first. You then move the existing Git history and W3DS integration, transfer an existing eName if there is one, and explicitly activate the public cutover.
+- A regular code import is not the same as porting a W3DS platform. Use the guided port flow when an existing platform identity must remain intact.
+
+Continue with [Sign in and manage your account](./sign-in-and-account), [Create a new platform](./create-a-platform), or [Port an existing application](./port-an-existing-application).
+
+## Before you begin
+
+You need:
+
+- an eID wallet with a W3DS identity;
+- Git installed locally if you will clone or push code;
+- an SSH key or a GitW3 personal access token for command-line Git authentication; and
+- repository owner or organization permissions for actions such as PPA submission and migration activation.
+
+For application integration work, GitW3 can give a supported coding agent the current W3DS skill:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+The skill helps the agent use current protocol concepts and ontology identifiers. It does not replace review, tests, or secret handling.

docs/docs/GitW3/platform-manifest-and-workspace.md

@@ -0,0 +1,94 @@
+---
+sidebar_position: 6
+title: Platform manifest and W3DS workspace
+description: Understand .w3ds/platform.json, asynchronous publication, visibility, and the repository W3DS tab.
+---
+
+# Platform manifest and W3DS workspace
+
+Every GitW3 platform repository owns a manifest at `.w3ds/platform.json`. It is version-controlled platform metadata and the source from which GitW3 publishes the platform profile to W3DS.
+
+## Manifest shape
+
+A newly created platform starts with the following core fields:
+
+```json
+{
+ "schemaVersion": 1,
+ "platformName": "example-platform",
+ "displayName": "Example Platform",
+ "description": "A short description of the platform.",
+ "version": "0.1.0",
+ "ename": null,
+ "url": "https://example.invalid",
+ "logoUrl": "https://example.invalid/logo.png",
+ "domains": ["productivity", "work"],
+ "inSubmission": false,
+ "submissionVersion": "",
+ "isDraft": true
+}
+```
+
+Use real W3DS ontology domain identifiers from the GitW3 selector. The values above are illustrative.
+
+## Who controls each field
+
+| Field | Control and behavior |
+| --- | --- |
+| `schemaVersion` | Manifest format version. Do not change it without a supported schema migration. |
+| `platformName` | Stable machine-facing platform slug derived at creation. Immutable after identity creation. |
+| `displayName` | Human-facing name. Editable by permitted repository users. |
+| `description` | Human-facing platform description. |
+| `version` | Synchronized from the latest stable semantic GitW3 release; do not manually bump it. |
+| `ename` | Permanent platform eName. Initially `null`, then written by the publisher or preserved by the port flow. Immutable once assigned. |
+| `url` | Public application URL. Required for PPA submission. |
+| `logoUrl` | Optional public logo URL. |
+| `domains` | One or more supported W3DS application-domain identifiers. |
+| `inSubmission` | Whether the current release statement is in the PPA review flow. Managed by the signed application workflow. |
+| `submissionVersion` | Version associated with the current signed PPA submission. |
+| `isDraft` | Controls whether the synchronized platform profile is hidden from the public marketplace. |
+
+Migration and PPA workflows can add proof fields. Never fabricate, copy between platforms, or hand-edit cryptographic proof material.
+
+## The W3DS workspace
+
+Open a platform repository and select **W3DS**. The page is organized around the platform lifecycle:
+
+1. **Live publication status** reports the publisher's current state and latest result.
+2. **What happens next** tracks manifest, permanent identity, application URL, and stable release readiness.
+3. **Marketplace visibility** switches the profile between draft and published.
+4. **Platform details** edits the display name, description, domains, application URL, and logo URL.
+5. **PPA certificate** shows the requirement checklist, signed application, review conversation, and current decision.
+
+Repository or organization permissions control who may edit details, change visibility, apply for PPA, or activate a migration. Read-only visitors see the manifest-backed values without the edit controls.
+
+## Saving changes
+
+Saving through the W3DS workspace creates a normal commit on the default branch. GitW3 checks the last observed commit so it does not silently overwrite a newer manifest change.
+
+For changes made locally:
+
+1. Pull the latest default branch.
+2. Edit only supported, non-managed fields.
+3. Validate the JSON and domain identifiers.
+4. Commit and push normally.
+5. Open the **W3DS** tab and watch publication status.
+
+Do not manually change `platformName`, an assigned `ename`, release-controlled `version`, or signed proof fields.
+
+## Identity and publication are asynchronous
+
+After the initial manifest reaches the default branch, GitW3's publisher:
+
+- reserves and publishes the permanent platform eName;
+- provisions the platform eVault without an application key;
+- writes the assigned eName back to the manifest; and
+- synchronizes the platform profile and its visibility.
+
+Repository creation and Git pushes remain available while this happens. Temporary W3DS failures are retried; refresh the **W3DS** tab to see the current state. Repository administrators can see a detailed last error when intervention is required.
+
+The platform eName gets the platform eVault. Version eNames are Registry records for exact releases and do not create additional eVaults.
+
+## Draft versus published
+
+New platforms begin as drafts. A synchronized draft profile is hidden from the marketplace but still belongs to the repository. Use **Publish platform** in the W3DS workspace when the profile is ready to be discoverable; use **Make draft** to hide it again without deleting its stable identity.

docs/docs/GitW3/_category_.json

@@ -0,0 +1,8 @@
+{
+ "label": "GitW3",
+ "position": 1.5,
+ "link": {
+ "type": "generated-index",
+ "description": "Sign in, create or port a W3DS platform, publish releases, apply for PPA, and register deployments with GitW3."
+ }
+}

docs/docs/GitW3/create-a-platform.md

@@ -0,0 +1,79 @@
+---
+sidebar_position: 3
+title: Create a new platform
+description: Create a repository, initial W3DS manifest, and permanent platform identity with GitW3.
+---
+
+# Create a new platform
+
+Use **Make a new platform** when the application does not already have a W3DS platform identity. GitW3 creates the repository and initial manifest, then provisions the permanent platform eName asynchronously.
+
+From the **+** menu, select **New repository**, then choose **Make a new platform**.
+
+![The GitW3 choice between making a new platform and porting an existing application.](/img/gitw3/choose-platform-path.png)
+
+## Step 1: Repository
+
+Choose the owner and describe where the code will live:
+
+1. Select your user or an organization as **Owner**.
+2. Decide whether the repository is private.
+3. Enter the human-facing **Display name**.
+4. Confirm the default branch, normally `main`.
+
+![Step one of the create-platform wizard, where the owner and display name are selected.](/img/gitw3/new-platform-repository.png)
+
+You do not choose a repository slug. GitW3 derives a URL-safe repository name and the initial stable `platformName` from the display name. If that name is already used under the owner, GitW3 adds a numeric suffix safely.
+
+The display name can change later. Treat `platformName` as the permanent machine-facing identity; GitW3 will not change it when the friendly name changes.
+
+## Step 2: Platform details
+
+Enter the information W3DS needs to describe the platform:
+
+- **Description:** a concise explanation of what the platform does;
+- **Application domains:** one or more domains from the W3DS ontology;
+- **Application URL:** the public URL, if the application is already deployed; and
+- **Logo URL:** an optional public image URL.
+
+![Step two of the create-platform wizard, with a description, W3DS domains, application URL, and logo URL.](/img/gitw3/new-platform-details.png)
+
+The version is controlled by Git releases, not entered in this form. The initial version is `0.1.0` until a stable semantic release becomes the repository's published version.
+
+You can leave the application URL empty while building. It is required before applying for PPA.
+
+## Step 3: AI setup
+
+Choose whether GitW3 should show the quick install for the W3DS coding-agent skill.
+
+![Step three of the create-platform wizard, offering the W3DS skill command for supported coding agents.](/img/gitw3/new-platform-ai-setup.png)
+
+The command works with supported agents including Codex, Claude Code, Cursor, Copilot, and Windsurf:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+Select **Create platform**. GitW3 creates:
+
+- the repository;
+- an initial README;
+- `.w3ds/platform.json`; and
+- the first commit on the default branch.
+
+It does not create or expose a reusable platform private key. The permanent platform identity and its eVault are provisioned automatically without an application or deployment key.
+
+## After creation
+
+The welcome page shows the permanent eName as soon as publication completes. Keep the page open or return to the **W3DS** tab later; provisioning continues in the background.
+
+Next:
+
+1. Clone the repository and push the application code.
+2. Open the **W3DS** tab and confirm the manifest and identity status.
+3. Add the public application URL when the deployment is reachable.
+4. Publish a stable semantic release such as `v0.1.0`.
+5. Apply for a PPA certificate for that exact version.
+6. Register a deployment from the **Deploy** tab.
+
+See [The platform manifest and W3DS workspace](./platform-manifest-and-workspace) for the generated file and editable fields.

docs/docs/GitW3/deploy-a-release.md

@@ -0,0 +1,99 @@
+---
+sidebar_position: 8
+title: Register a deployment
+description: Create and sign a verifiable W3DS deployment record for a PPA-certified release.
+---
+
+# Register a deployment
+
+The GitW3 **Deploy** tab registers a verifiable W3DS deployment identity for a published release. It binds the exact code version, deployment environment, connected deployer, and a public application key.
+
+:::important
+
+This flow does not upload or run the application. Deploy the code with your normal hosting provider or pipeline, then use the generated key in that server or runtime when PP-Auth integration is available.
+
+:::
+
+## Prerequisites
+
+Before starting, confirm:
+
+- the platform eName is ready;
+- a stable semantic release is published;
+- PPA has granted a certificate for that exact version;
+- you are signed in with the eID wallet that will act as the deployer; and
+- the W3DS deployment publisher is available.
+
+Every deployment belongs to the connected deployer's eName. It does not claim that the platform authors or release committers operated the deployment.
+
+## Step 1: Choose release
+
+Open **Deploy** and select a PPA-certified release. The release binds the version tag and exact commit to the stable platform eName. Uncertified releases remain unavailable.
+
+You can register additional versions later without replacing earlier records.
+
+## Step 2: Describe deployment
+
+Enter a human-friendly name such as `Singapore production`, then choose an environment:
+
+- Production
+- Staging
+- Development
+- Custom
+
+These values distinguish multiple deployments of the same release. They do not configure a hosting region, DNS record, or deployment pipeline.
+
+## Step 3: Bind an application key
+
+Choose one of two key paths:
+
+### Generate a deployment key
+
+This is recommended for a first deployment. GitW3 generates an ECDSA P-256 key pair in the browser and downloads `w3ds-deployment-key.json` immediately. The backup uses the `w3ds-deployment-key-v1` format and contains:
+
+- algorithm metadata for ECDSA P-256 with SHA-256;
+- the `z`-prefixed public key;
+- the base64-encoded PKCS#8 private key; and
+- a creation timestamp.
+
+Confirm that the file was downloaded and stored safely before continuing.
+
+### Use an existing public key
+
+Choose this path when your runtime or secret manager already controls a compatible W3DS P-256 key. Paste only the `z`-prefixed public key. Do not upload or paste the private key into GitW3.
+
+:::danger The private key is shown only through the download
+
+GitW3 receives the public key and cannot recover the private key. Never commit `w3ds-deployment-key.json`, paste it into chat, expose it through an API, or ship it in a browser or mobile bundle.
+
+:::
+
+Store the private file in the hosting provider's secret manager or a read-only server mount. Prefer an environment variable such as `W3DS_DEPLOYMENT_KEY_FILE` that points to the mounted file instead of putting key material in an environment variable.
+
+## Step 4: Review and sign
+
+Review the release, deployment name, environment, deployer identity, and key handling confirmation. GitW3 reserves two identities:
+
+- a **deployment eName** bound to the deployment's public key and connected deployer; and
+- a **software-version eName** bound to the stable platform eName, release version, and exact Git commit.
+
+Select **Create identities and continue to wallet**, then scan or open the eID wallet. One wallet signature covers both documents. Nothing is provisioned until the signature is verified.
+
+## Publication and server integration
+
+The deployment card progresses through publishing, waiting for W3DS, published, or needs-attention states. After publication it shows both eNames and a **Use AI to configure the server** helper.
+
+That generated prompt contains the verified public deployment context but not the private key. It asks a coding assistant to:
+
+- inspect the existing server runtime and deployment method;
+- add a server-only loader for `w3ds-deployment-key-v1`;
+- validate P-256/SHA-256 and ensure the private key derives the expected public key;
+- keep key loading unreachable from client code;
+- use a secret manager or read-only mount; and
+- leave a narrow PP-Auth integration boundary without inventing an unpublished SDK or protocol.
+
+Keep the downloaded private-key file local when using that prompt. PP-Auth SDK integration is marked as coming soon in GitW3; do not invent a package name, endpoint, token format, or wire protocol.
+
+## Rotation and recovery
+
+If the private key is lost, GitW3 cannot restore it. Register a new deployment identity and update the server secret through a controlled rollout. Keep the old secret available only for the rollback window, verify the new public-key match at startup, then revoke or destroy the old secret according to your hosting policy.

docs/docs/GitW3/overview.md

@@ -0,0 +1,70 @@
+---
+sidebar_position: 1
+title: GitW3 overview
+description: Start here to understand GitW3 repositories, W3DS identities, releases, certification, and deployment records.
+---
+
+# GitW3 overview
+
+[GitW3](https://git.w3ds.metastate.foundation) is the W3DS-aware Git forge. It hosts source code and normal collaborative Git workflows, while connecting a platform repository to its permanent W3DS identity, published versions, PPA certificates, and verifiable deployment records.
+
+GitW3 is built around one rule: the repository is the source of truth for the platform metadata that W3DS publishes. The metadata lives beside the code in `.w3ds/platform.json`, and changes made from the GitW3 **W3DS** tab become ordinary commits on the default branch.
+
+## What GitW3 manages
+
+| Item | Meaning | Where you work with it |
+| --- | --- | --- |
+| Repository | Source code, issues, pull requests, tags, and releases | The regular repository tabs and Git |
+| Platform manifest | Version-controlled W3DS metadata | `.w3ds/platform.json` and the **W3DS** tab |
+| Platform eName | The permanent identity of the platform across releases | Provisioned automatically and shown on the **W3DS** tab |
+| Version eName | The identity of one exact released version | Derived from a stable Git release |
+| PPA certificate | Approval for one exact platform version | Apply and follow the review from the **W3DS** tab |
+| Deployment eName | A verifiable record of one running deployment | Created from the **Deploy** tab |
+
+The platform eName remains stable when the code, release, or deployment changes. Each released software version and each deployment receives its own identity so that W3DS records can refer to an exact artifact or running instance.
+
+:::important GitW3 records deployments; it does not host them
+
+The **Deploy** flow creates W3DS identities and attestations. Continue using your normal hosting provider or deployment pipeline to run the application.
+
+:::
+
+## The normal platform lifecycle
+
+```mermaid
+flowchart LR
+ A[Sign in with W3DS] --> B[Create or port a repository]
+ B --> C[Platform manifest committed]
+ C --> D[Permanent platform eName provisioned]
+ D --> E[Publish a stable release]
+ E --> F[Sign and submit PPA application]
+ F --> G[PPA certificate granted]
+ G --> H[Register and sign a deployment]
+```
+
+Identity and profile publication happen asynchronously. Git pushes and repository creation do not wait synchronously for every W3DS service. The status shown on the **W3DS** tab updates as the publisher completes or retries the work.
+
+## Choose the right starting path
+
+- **Make a new platform** creates a repository, an initial README, and `.w3ds/platform.json`. Use it when the application does not already have a W3DS identity.
+- **Port an existing app** creates an empty destination first. You then move the existing Git history and W3DS integration, transfer an existing eName if there is one, and explicitly activate the public cutover.
+- A regular code import is not the same as porting a W3DS platform. Use the guided port flow when an existing platform identity must remain intact.
+
+Continue with [Sign in and manage your account](./sign-in-and-account), [Create a new platform](./create-a-platform), or [Port an existing application](./port-an-existing-application).
+
+## Before you begin
+
+You need:
+
+- an eID wallet with a W3DS identity;
+- Git installed locally if you will clone or push code;
+- an SSH key or a GitW3 personal access token for command-line Git authentication; and
+- repository owner or organization permissions for actions such as PPA submission and migration activation.
+
+For application integration work, GitW3 can give a supported coding agent the current W3DS skill:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+The skill helps the agent use current protocol concepts and ontology identifiers. It does not replace review, tests, or secret handling.

docs/docs/GitW3/platform-manifest-and-workspace.md

@@ -0,0 +1,94 @@
+---
+sidebar_position: 6
+title: Platform manifest and W3DS workspace
+description: Understand .w3ds/platform.json, asynchronous publication, visibility, and the repository W3DS tab.
+---
+
+# Platform manifest and W3DS workspace
+
+Every GitW3 platform repository owns a manifest at `.w3ds/platform.json`. It is version-controlled platform metadata and the source from which GitW3 publishes the platform profile to W3DS.
+
+## Manifest shape
+
+A newly created platform starts with the following core fields:
+
+```json
+{
+ "schemaVersion": 1,
+ "platformName": "example-platform",
+ "displayName": "Example Platform",
+ "description": "A short description of the platform.",
+ "version": "0.1.0",
+ "ename": null,
+ "url": "https://example.invalid",
+ "logoUrl": "https://example.invalid/logo.png",
+ "domains": ["productivity", "work"],
+ "inSubmission": false,
+ "submissionVersion": "",
+ "isDraft": true
+}
+```
+
+Use real W3DS ontology domain identifiers from the GitW3 selector. The values above are illustrative.
+
+## Who controls each field
+
+| Field | Control and behavior |
+| --- | --- |
+| `schemaVersion` | Manifest format version. Do not change it without a supported schema migration. |
+| `platformName` | Stable machine-facing platform slug derived at creation. Immutable after identity creation. |
+| `displayName` | Human-facing name. Editable by permitted repository users. |
+| `description` | Human-facing platform description. |
+| `version` | Synchronized from the latest stable semantic GitW3 release; do not manually bump it. |
+| `ename` | Permanent platform eName. Initially `null`, then written by the publisher or preserved by the port flow. Immutable once assigned. |
+| `url` | Public application URL. Required for PPA submission. |
+| `logoUrl` | Optional public logo URL. |
+| `domains` | One or more supported W3DS application-domain identifiers. |
+| `inSubmission` | Whether the current release statement is in the PPA review flow. Managed by the signed application workflow. |
+| `submissionVersion` | Version associated with the current signed PPA submission. |
+| `isDraft` | Controls whether the synchronized platform profile is hidden from the public marketplace. |
+
+Migration and PPA workflows can add proof fields. Never fabricate, copy between platforms, or hand-edit cryptographic proof material.
+
+## The W3DS workspace
+
+Open a platform repository and select **W3DS**. The page is organized around the platform lifecycle:
+
+1. **Live publication status** reports the publisher's current state and latest result.
+2. **What happens next** tracks manifest, permanent identity, application URL, and stable release readiness.
+3. **Marketplace visibility** switches the profile between draft and published.
+4. **Platform details** edits the display name, description, domains, application URL, and logo URL.
+5. **PPA certificate** shows the requirement checklist, signed application, review conversation, and current decision.
+
+Repository or organization permissions control who may edit details, change visibility, apply for PPA, or activate a migration. Read-only visitors see the manifest-backed values without the edit controls.
+
+## Saving changes
+
+Saving through the W3DS workspace creates a normal commit on the default branch. GitW3 checks the last observed commit so it does not silently overwrite a newer manifest change.
+
+For changes made locally:
+
+1. Pull the latest default branch.
+2. Edit only supported, non-managed fields.
+3. Validate the JSON and domain identifiers.
+4. Commit and push normally.
+5. Open the **W3DS** tab and watch publication status.
+
+Do not manually change `platformName`, an assigned `ename`, release-controlled `version`, or signed proof fields.
+
+## Identity and publication are asynchronous
+
+After the initial manifest reaches the default branch, GitW3's publisher:
+
+- reserves and publishes the permanent platform eName;
+- provisions the platform eVault without an application key;
+- writes the assigned eName back to the manifest; and
+- synchronizes the platform profile and its visibility.
+
+Repository creation and Git pushes remain available while this happens. Temporary W3DS failures are retried; refresh the **W3DS** tab to see the current state. Repository administrators can see a detailed last error when intervention is required.
+
+The platform eName gets the platform eVault. Version eNames are Registry records for exact releases and do not create additional eVaults.
+
+## Draft versus published
+
+New platforms begin as drafts. A synchronized draft profile is hidden from the marketplace but still belongs to the repository. Use **Publish platform** in the W3DS workspace when the profile is ready to be discoverable; use **Make draft** to hide it again without deleting its stable identity.

docs/docs/GitW3/_category_.json

@@ -0,0 +1,8 @@
+{
+ "label": "GitW3",
+ "position": 1.5,
+ "link": {
+ "type": "generated-index",
+ "description": "Sign in, create or port a W3DS platform, publish releases, apply for PPA, and register deployments with GitW3."
+ }
+}

docs/docs/GitW3/create-a-platform.md

@@ -0,0 +1,79 @@
+---
+sidebar_position: 3
+title: Create a new platform
+description: Create a repository, initial W3DS manifest, and permanent platform identity with GitW3.
+---
+
+# Create a new platform
+
+Use **Make a new platform** when the application does not already have a W3DS platform identity. GitW3 creates the repository and initial manifest, then provisions the permanent platform eName asynchronously.
+
+From the **+** menu, select **New repository**, then choose **Make a new platform**.
+
+![The GitW3 choice between making a new platform and porting an existing application.](/img/gitw3/choose-platform-path.png)
+
+## Step 1: Repository
+
+Choose the owner and describe where the code will live:
+
+1. Select your user or an organization as **Owner**.
+2. Decide whether the repository is private.
+3. Enter the human-facing **Display name**.
+4. Confirm the default branch, normally `main`.
+
+![Step one of the create-platform wizard, where the owner and display name are selected.](/img/gitw3/new-platform-repository.png)
+
+You do not choose a repository slug. GitW3 derives a URL-safe repository name and the initial stable `platformName` from the display name. If that name is already used under the owner, GitW3 adds a numeric suffix safely.
+
+The display name can change later. Treat `platformName` as the permanent machine-facing identity; GitW3 will not change it when the friendly name changes.
+
+## Step 2: Platform details
+
+Enter the information W3DS needs to describe the platform:
+
+- **Description:** a concise explanation of what the platform does;
+- **Application domains:** one or more domains from the W3DS ontology;
+- **Application URL:** the public URL, if the application is already deployed; and
+- **Logo URL:** an optional public image URL.
+
+![Step two of the create-platform wizard, with a description, W3DS domains, application URL, and logo URL.](/img/gitw3/new-platform-details.png)
+
+The version is controlled by Git releases, not entered in this form. The initial version is `0.1.0` until a stable semantic release becomes the repository's published version.
+
+You can leave the application URL empty while building. It is required before applying for PPA.
+
+## Step 3: AI setup
+
+Choose whether GitW3 should show the quick install for the W3DS coding-agent skill.
+
+![Step three of the create-platform wizard, offering the W3DS skill command for supported coding agents.](/img/gitw3/new-platform-ai-setup.png)
+
+The command works with supported agents including Codex, Claude Code, Cursor, Copilot, and Windsurf:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+Select **Create platform**. GitW3 creates:
+
+- the repository;
+- an initial README;
+- `.w3ds/platform.json`; and
+- the first commit on the default branch.
+
+It does not create or expose a reusable platform private key. The permanent platform identity and its eVault are provisioned automatically without an application or deployment key.
+
+## After creation
+
+The welcome page shows the permanent eName as soon as publication completes. Keep the page open or return to the **W3DS** tab later; provisioning continues in the background.
+
+Next:
+
+1. Clone the repository and push the application code.
+2. Open the **W3DS** tab and confirm the manifest and identity status.
+3. Add the public application URL when the deployment is reachable.
+4. Publish a stable semantic release such as `v0.1.0`.
+5. Apply for a PPA certificate for that exact version.
+6. Register a deployment from the **Deploy** tab.
+
+See [The platform manifest and W3DS workspace](./platform-manifest-and-workspace) for the generated file and editable fields.

docs/docs/GitW3/deploy-a-release.md

@@ -0,0 +1,99 @@
+---
+sidebar_position: 8
+title: Register a deployment
+description: Create and sign a verifiable W3DS deployment record for a PPA-certified release.
+---
+
+# Register a deployment
+
+The GitW3 **Deploy** tab registers a verifiable W3DS deployment identity for a published release. It binds the exact code version, deployment environment, connected deployer, and a public application key.
+
+:::important
+
+This flow does not upload or run the application. Deploy the code with your normal hosting provider or pipeline, then use the generated key in that server or runtime when PP-Auth integration is available.
+
+:::
+
+## Prerequisites
+
+Before starting, confirm:
+
+- the platform eName is ready;
+- a stable semantic release is published;
+- PPA has granted a certificate for that exact version;
+- you are signed in with the eID wallet that will act as the deployer; and
+- the W3DS deployment publisher is available.
+
+Every deployment belongs to the connected deployer's eName. It does not claim that the platform authors or release committers operated the deployment.
+
+## Step 1: Choose release
+
+Open **Deploy** and select a PPA-certified release. The release binds the version tag and exact commit to the stable platform eName. Uncertified releases remain unavailable.
+
+You can register additional versions later without replacing earlier records.
+
+## Step 2: Describe deployment
+
+Enter a human-friendly name such as `Singapore production`, then choose an environment:
+
+- Production
+- Staging
+- Development
+- Custom
+
+These values distinguish multiple deployments of the same release. They do not configure a hosting region, DNS record, or deployment pipeline.
+
+## Step 3: Bind an application key
+
+Choose one of two key paths:
+
+### Generate a deployment key
+
+This is recommended for a first deployment. GitW3 generates an ECDSA P-256 key pair in the browser and downloads `w3ds-deployment-key.json` immediately. The backup uses the `w3ds-deployment-key-v1` format and contains:
+
+- algorithm metadata for ECDSA P-256 with SHA-256;
+- the `z`-prefixed public key;
+- the base64-encoded PKCS#8 private key; and
+- a creation timestamp.
+
+Confirm that the file was downloaded and stored safely before continuing.
+
+### Use an existing public key
+
+Choose this path when your runtime or secret manager already controls a compatible W3DS P-256 key. Paste only the `z`-prefixed public key. Do not upload or paste the private key into GitW3.
+
+:::danger The private key is shown only through the download
+
+GitW3 receives the public key and cannot recover the private key. Never commit `w3ds-deployment-key.json`, paste it into chat, expose it through an API, or ship it in a browser or mobile bundle.
+
+:::
+
+Store the private file in the hosting provider's secret manager or a read-only server mount. Prefer an environment variable such as `W3DS_DEPLOYMENT_KEY_FILE` that points to the mounted file instead of putting key material in an environment variable.
+
+## Step 4: Review and sign
+
+Review the release, deployment name, environment, deployer identity, and key handling confirmation. GitW3 reserves two identities:
+
+- a **deployment eName** bound to the deployment's public key and connected deployer; and
+- a **software-version eName** bound to the stable platform eName, release version, and exact Git commit.
+
+Select **Create identities and continue to wallet**, then scan or open the eID wallet. One wallet signature covers both documents. Nothing is provisioned until the signature is verified.
+
+## Publication and server integration
+
+The deployment card progresses through publishing, waiting for W3DS, published, or needs-attention states. After publication it shows both eNames and a **Use AI to configure the server** helper.
+
+That generated prompt contains the verified public deployment context but not the private key. It asks a coding assistant to:
+
+- inspect the existing server runtime and deployment method;
+- add a server-only loader for `w3ds-deployment-key-v1`;
+- validate P-256/SHA-256 and ensure the private key derives the expected public key;
+- keep key loading unreachable from client code;
+- use a secret manager or read-only mount; and
+- leave a narrow PP-Auth integration boundary without inventing an unpublished SDK or protocol.
+
+Keep the downloaded private-key file local when using that prompt. PP-Auth SDK integration is marked as coming soon in GitW3; do not invent a package name, endpoint, token format, or wire protocol.
+
+## Rotation and recovery
+
+If the private key is lost, GitW3 cannot restore it. Register a new deployment identity and update the server secret through a controlled rollout. Keep the old secret available only for the rollback window, verify the new public-key match at startup, then revoke or destroy the old secret according to your hosting policy.

docs/docs/GitW3/overview.md

@@ -0,0 +1,70 @@
+---
+sidebar_position: 1
+title: GitW3 overview
+description: Start here to understand GitW3 repositories, W3DS identities, releases, certification, and deployment records.
+---
+
+# GitW3 overview
+
+[GitW3](https://git.w3ds.metastate.foundation) is the W3DS-aware Git forge. It hosts source code and normal collaborative Git workflows, while connecting a platform repository to its permanent W3DS identity, published versions, PPA certificates, and verifiable deployment records.
+
+GitW3 is built around one rule: the repository is the source of truth for the platform metadata that W3DS publishes. The metadata lives beside the code in `.w3ds/platform.json`, and changes made from the GitW3 **W3DS** tab become ordinary commits on the default branch.
+
+## What GitW3 manages
+
+| Item | Meaning | Where you work with it |
+| --- | --- | --- |
+| Repository | Source code, issues, pull requests, tags, and releases | The regular repository tabs and Git |
+| Platform manifest | Version-controlled W3DS metadata | `.w3ds/platform.json` and the **W3DS** tab |
+| Platform eName | The permanent identity of the platform across releases | Provisioned automatically and shown on the **W3DS** tab |
+| Version eName | The identity of one exact released version | Derived from a stable Git release |
+| PPA certificate | Approval for one exact platform version | Apply and follow the review from the **W3DS** tab |
+| Deployment eName | A verifiable record of one running deployment | Created from the **Deploy** tab |
+
+The platform eName remains stable when the code, release, or deployment changes. Each released software version and each deployment receives its own identity so that W3DS records can refer to an exact artifact or running instance.
+
+:::important GitW3 records deployments; it does not host them
+
+The **Deploy** flow creates W3DS identities and attestations. Continue using your normal hosting provider or deployment pipeline to run the application.
+
+:::
+
+## The normal platform lifecycle
+
+```mermaid
+flowchart LR
+ A[Sign in with W3DS] --> B[Create or port a repository]
+ B --> C[Platform manifest committed]
+ C --> D[Permanent platform eName provisioned]
+ D --> E[Publish a stable release]
+ E --> F[Sign and submit PPA application]
+ F --> G[PPA certificate granted]
+ G --> H[Register and sign a deployment]
+```
+
+Identity and profile publication happen asynchronously. Git pushes and repository creation do not wait synchronously for every W3DS service. The status shown on the **W3DS** tab updates as the publisher completes or retries the work.
+
+## Choose the right starting path
+
+- **Make a new platform** creates a repository, an initial README, and `.w3ds/platform.json`. Use it when the application does not already have a W3DS identity.
+- **Port an existing app** creates an empty destination first. You then move the existing Git history and W3DS integration, transfer an existing eName if there is one, and explicitly activate the public cutover.
+- A regular code import is not the same as porting a W3DS platform. Use the guided port flow when an existing platform identity must remain intact.
+
+Continue with [Sign in and manage your account](./sign-in-and-account), [Create a new platform](./create-a-platform), or [Port an existing application](./port-an-existing-application).
+
+## Before you begin
+
+You need:
+
+- an eID wallet with a W3DS identity;
+- Git installed locally if you will clone or push code;
+- an SSH key or a GitW3 personal access token for command-line Git authentication; and
+- repository owner or organization permissions for actions such as PPA submission and migration activation.
+
+For application integration work, GitW3 can give a supported coding agent the current W3DS skill:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+The skill helps the agent use current protocol concepts and ontology identifiers. It does not replace review, tests, or secret handling.

docs/docs/GitW3/platform-manifest-and-workspace.md

@@ -0,0 +1,94 @@
+---
+sidebar_position: 6
+title: Platform manifest and W3DS workspace
+description: Understand .w3ds/platform.json, asynchronous publication, visibility, and the repository W3DS tab.
+---
+
+# Platform manifest and W3DS workspace
+
+Every GitW3 platform repository owns a manifest at `.w3ds/platform.json`. It is version-controlled platform metadata and the source from which GitW3 publishes the platform profile to W3DS.
+
+## Manifest shape
+
+A newly created platform starts with the following core fields:
+
+```json
+{
+ "schemaVersion": 1,
+ "platformName": "example-platform",
+ "displayName": "Example Platform",
+ "description": "A short description of the platform.",
+ "version": "0.1.0",
+ "ename": null,
+ "url": "https://example.invalid",
+ "logoUrl": "https://example.invalid/logo.png",
+ "domains": ["productivity", "work"],
+ "inSubmission": false,
+ "submissionVersion": "",
+ "isDraft": true
+}
+```
+
+Use real W3DS ontology domain identifiers from the GitW3 selector. The values above are illustrative.
+
+## Who controls each field
+
+| Field | Control and behavior |
+| --- | --- |
+| `schemaVersion` | Manifest format version. Do not change it without a supported schema migration. |
+| `platformName` | Stable machine-facing platform slug derived at creation. Immutable after identity creation. |
+| `displayName` | Human-facing name. Editable by permitted repository users. |
+| `description` | Human-facing platform description. |
+| `version` | Synchronized from the latest stable semantic GitW3 release; do not manually bump it. |
+| `ename` | Permanent platform eName. Initially `null`, then written by the publisher or preserved by the port flow. Immutable once assigned. |
+| `url` | Public application URL. Required for PPA submission. |
+| `logoUrl` | Optional public logo URL. |
+| `domains` | One or more supported W3DS application-domain identifiers. |
+| `inSubmission` | Whether the current release statement is in the PPA review flow. Managed by the signed application workflow. |
+| `submissionVersion` | Version associated with the current signed PPA submission. |
+| `isDraft` | Controls whether the synchronized platform profile is hidden from the public marketplace. |
+
+Migration and PPA workflows can add proof fields. Never fabricate, copy between platforms, or hand-edit cryptographic proof material.
+
+## The W3DS workspace
+
+Open a platform repository and select **W3DS**. The page is organized around the platform lifecycle:
+
+1. **Live publication status** reports the publisher's current state and latest result.
+2. **What happens next** tracks manifest, permanent identity, application URL, and stable release readiness.
+3. **Marketplace visibility** switches the profile between draft and published.
+4. **Platform details** edits the display name, description, domains, application URL, and logo URL.
+5. **PPA certificate** shows the requirement checklist, signed application, review conversation, and current decision.
+
+Repository or organization permissions control who may edit details, change visibility, apply for PPA, or activate a migration. Read-only visitors see the manifest-backed values without the edit controls.
+
+## Saving changes
+
+Saving through the W3DS workspace creates a normal commit on the default branch. GitW3 checks the last observed commit so it does not silently overwrite a newer manifest change.
+
+For changes made locally:
+
+1. Pull the latest default branch.
+2. Edit only supported, non-managed fields.
+3. Validate the JSON and domain identifiers.
+4. Commit and push normally.
+5. Open the **W3DS** tab and watch publication status.
+
+Do not manually change `platformName`, an assigned `ename`, release-controlled `version`, or signed proof fields.
+
+## Identity and publication are asynchronous
+
+After the initial manifest reaches the default branch, GitW3's publisher:
+
+- reserves and publishes the permanent platform eName;
+- provisions the platform eVault without an application key;
+- writes the assigned eName back to the manifest; and
+- synchronizes the platform profile and its visibility.
+
+Repository creation and Git pushes remain available while this happens. Temporary W3DS failures are retried; refresh the **W3DS** tab to see the current state. Repository administrators can see a detailed last error when intervention is required.
+
+The platform eName gets the platform eVault. Version eNames are Registry records for exact releases and do not create additional eVaults.
+
+## Draft versus published
+
+New platforms begin as drafts. A synchronized draft profile is hidden from the marketplace but still belongs to the repository. Use **Publish platform** in the W3DS workspace when the profile is ready to be discoverable; use **Make draft** to hide it again without deleting its stable identity.

docs/docs/GitW3/_category_.json

@@ -0,0 +1,8 @@
+{
+ "label": "GitW3",
+ "position": 1.5,
+ "link": {
+ "type": "generated-index",
+ "description": "Sign in, create or port a W3DS platform, publish releases, apply for PPA, and register deployments with GitW3."
+ }
+}

docs/docs/GitW3/create-a-platform.md

@@ -0,0 +1,79 @@
+---
+sidebar_position: 3
+title: Create a new platform
+description: Create a repository, initial W3DS manifest, and permanent platform identity with GitW3.
+---
+
+# Create a new platform
+
+Use **Make a new platform** when the application does not already have a W3DS platform identity. GitW3 creates the repository and initial manifest, then provisions the permanent platform eName asynchronously.
+
+From the **+** menu, select **New repository**, then choose **Make a new platform**.
+
+![The GitW3 choice between making a new platform and porting an existing application.](/img/gitw3/choose-platform-path.png)
+
+## Step 1: Repository
+
+Choose the owner and describe where the code will live:
+
+1. Select your user or an organization as **Owner**.
+2. Decide whether the repository is private.
+3. Enter the human-facing **Display name**.
+4. Confirm the default branch, normally `main`.
+
+![Step one of the create-platform wizard, where the owner and display name are selected.](/img/gitw3/new-platform-repository.png)
+
+You do not choose a repository slug. GitW3 derives a URL-safe repository name and the initial stable `platformName` from the display name. If that name is already used under the owner, GitW3 adds a numeric suffix safely.
+
+The display name can change later. Treat `platformName` as the permanent machine-facing identity; GitW3 will not change it when the friendly name changes.
+
+## Step 2: Platform details
+
+Enter the information W3DS needs to describe the platform:
+
+- **Description:** a concise explanation of what the platform does;
+- **Application domains:** one or more domains from the W3DS ontology;
+- **Application URL:** the public URL, if the application is already deployed; and
+- **Logo URL:** an optional public image URL.
+
+![Step two of the create-platform wizard, with a description, W3DS domains, application URL, and logo URL.](/img/gitw3/new-platform-details.png)
+
+The version is controlled by Git releases, not entered in this form. The initial version is `0.1.0` until a stable semantic release becomes the repository's published version.
+
+You can leave the application URL empty while building. It is required before applying for PPA.
+
+## Step 3: AI setup
+
+Choose whether GitW3 should show the quick install for the W3DS coding-agent skill.
+
+![Step three of the create-platform wizard, offering the W3DS skill command for supported coding agents.](/img/gitw3/new-platform-ai-setup.png)
+
+The command works with supported agents including Codex, Claude Code, Cursor, Copilot, and Windsurf:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+Select **Create platform**. GitW3 creates:
+
+- the repository;
+- an initial README;
+- `.w3ds/platform.json`; and
+- the first commit on the default branch.
+
+It does not create or expose a reusable platform private key. The permanent platform identity and its eVault are provisioned automatically without an application or deployment key.
+
+## After creation
+
+The welcome page shows the permanent eName as soon as publication completes. Keep the page open or return to the **W3DS** tab later; provisioning continues in the background.
+
+Next:
+
+1. Clone the repository and push the application code.
+2. Open the **W3DS** tab and confirm the manifest and identity status.
+3. Add the public application URL when the deployment is reachable.
+4. Publish a stable semantic release such as `v0.1.0`.
+5. Apply for a PPA certificate for that exact version.
+6. Register a deployment from the **Deploy** tab.
+
+See [The platform manifest and W3DS workspace](./platform-manifest-and-workspace) for the generated file and editable fields.

docs/docs/GitW3/deploy-a-release.md

@@ -0,0 +1,99 @@
+---
+sidebar_position: 8
+title: Register a deployment
+description: Create and sign a verifiable W3DS deployment record for a PPA-certified release.
+---
+
+# Register a deployment
+
+The GitW3 **Deploy** tab registers a verifiable W3DS deployment identity for a published release. It binds the exact code version, deployment environment, connected deployer, and a public application key.
+
+:::important
+
+This flow does not upload or run the application. Deploy the code with your normal hosting provider or pipeline, then use the generated key in that server or runtime when PP-Auth integration is available.
+
+:::
+
+## Prerequisites
+
+Before starting, confirm:
+
+- the platform eName is ready;
+- a stable semantic release is published;
+- PPA has granted a certificate for that exact version;
+- you are signed in with the eID wallet that will act as the deployer; and
+- the W3DS deployment publisher is available.
+
+Every deployment belongs to the connected deployer's eName. It does not claim that the platform authors or release committers operated the deployment.
+
+## Step 1: Choose release
+
+Open **Deploy** and select a PPA-certified release. The release binds the version tag and exact commit to the stable platform eName. Uncertified releases remain unavailable.
+
+You can register additional versions later without replacing earlier records.
+
+## Step 2: Describe deployment
+
+Enter a human-friendly name such as `Singapore production`, then choose an environment:
+
+- Production
+- Staging
+- Development
+- Custom
+
+These values distinguish multiple deployments of the same release. They do not configure a hosting region, DNS record, or deployment pipeline.
+
+## Step 3: Bind an application key
+
+Choose one of two key paths:
+
+### Generate a deployment key
+
+This is recommended for a first deployment. GitW3 generates an ECDSA P-256 key pair in the browser and downloads `w3ds-deployment-key.json` immediately. The backup uses the `w3ds-deployment-key-v1` format and contains:
+
+- algorithm metadata for ECDSA P-256 with SHA-256;
+- the `z`-prefixed public key;
+- the base64-encoded PKCS#8 private key; and
+- a creation timestamp.
+
+Confirm that the file was downloaded and stored safely before continuing.
+
+### Use an existing public key
+
+Choose this path when your runtime or secret manager already controls a compatible W3DS P-256 key. Paste only the `z`-prefixed public key. Do not upload or paste the private key into GitW3.
+
+:::danger The private key is shown only through the download
+
+GitW3 receives the public key and cannot recover the private key. Never commit `w3ds-deployment-key.json`, paste it into chat, expose it through an API, or ship it in a browser or mobile bundle.
+
+:::
+
+Store the private file in the hosting provider's secret manager or a read-only server mount. Prefer an environment variable such as `W3DS_DEPLOYMENT_KEY_FILE` that points to the mounted file instead of putting key material in an environment variable.
+
+## Step 4: Review and sign
+
+Review the release, deployment name, environment, deployer identity, and key handling confirmation. GitW3 reserves two identities:
+
+- a **deployment eName** bound to the deployment's public key and connected deployer; and
+- a **software-version eName** bound to the stable platform eName, release version, and exact Git commit.
+
+Select **Create identities and continue to wallet**, then scan or open the eID wallet. One wallet signature covers both documents. Nothing is provisioned until the signature is verified.
+
+## Publication and server integration
+
+The deployment card progresses through publishing, waiting for W3DS, published, or needs-attention states. After publication it shows both eNames and a **Use AI to configure the server** helper.
+
+That generated prompt contains the verified public deployment context but not the private key. It asks a coding assistant to:
+
+- inspect the existing server runtime and deployment method;
+- add a server-only loader for `w3ds-deployment-key-v1`;
+- validate P-256/SHA-256 and ensure the private key derives the expected public key;
+- keep key loading unreachable from client code;
+- use a secret manager or read-only mount; and
+- leave a narrow PP-Auth integration boundary without inventing an unpublished SDK or protocol.
+
+Keep the downloaded private-key file local when using that prompt. PP-Auth SDK integration is marked as coming soon in GitW3; do not invent a package name, endpoint, token format, or wire protocol.
+
+## Rotation and recovery
+
+If the private key is lost, GitW3 cannot restore it. Register a new deployment identity and update the server secret through a controlled rollout. Keep the old secret available only for the rollback window, verify the new public-key match at startup, then revoke or destroy the old secret according to your hosting policy.

docs/docs/GitW3/overview.md

@@ -0,0 +1,70 @@
+---
+sidebar_position: 1
+title: GitW3 overview
+description: Start here to understand GitW3 repositories, W3DS identities, releases, certification, and deployment records.
+---
+
+# GitW3 overview
+
+[GitW3](https://git.w3ds.metastate.foundation) is the W3DS-aware Git forge. It hosts source code and normal collaborative Git workflows, while connecting a platform repository to its permanent W3DS identity, published versions, PPA certificates, and verifiable deployment records.
+
+GitW3 is built around one rule: the repository is the source of truth for the platform metadata that W3DS publishes. The metadata lives beside the code in `.w3ds/platform.json`, and changes made from the GitW3 **W3DS** tab become ordinary commits on the default branch.
+
+## What GitW3 manages
+
+| Item | Meaning | Where you work with it |
+| --- | --- | --- |
+| Repository | Source code, issues, pull requests, tags, and releases | The regular repository tabs and Git |
+| Platform manifest | Version-controlled W3DS metadata | `.w3ds/platform.json` and the **W3DS** tab |
+| Platform eName | The permanent identity of the platform across releases | Provisioned automatically and shown on the **W3DS** tab |
+| Version eName | The identity of one exact released version | Derived from a stable Git release |
+| PPA certificate | Approval for one exact platform version | Apply and follow the review from the **W3DS** tab |
+| Deployment eName | A verifiable record of one running deployment | Created from the **Deploy** tab |
+
+The platform eName remains stable when the code, release, or deployment changes. Each released software version and each deployment receives its own identity so that W3DS records can refer to an exact artifact or running instance.
+
+:::important GitW3 records deployments; it does not host them
+
+The **Deploy** flow creates W3DS identities and attestations. Continue using your normal hosting provider or deployment pipeline to run the application.
+
+:::
+
+## The normal platform lifecycle
+
+```mermaid
+flowchart LR
+ A[Sign in with W3DS] --> B[Create or port a repository]
+ B --> C[Platform manifest committed]
+ C --> D[Permanent platform eName provisioned]
+ D --> E[Publish a stable release]
+ E --> F[Sign and submit PPA application]
+ F --> G[PPA certificate granted]
+ G --> H[Register and sign a deployment]
+```
+
+Identity and profile publication happen asynchronously. Git pushes and repository creation do not wait synchronously for every W3DS service. The status shown on the **W3DS** tab updates as the publisher completes or retries the work.
+
+## Choose the right starting path
+
+- **Make a new platform** creates a repository, an initial README, and `.w3ds/platform.json`. Use it when the application does not already have a W3DS identity.
+- **Port an existing app** creates an empty destination first. You then move the existing Git history and W3DS integration, transfer an existing eName if there is one, and explicitly activate the public cutover.
+- A regular code import is not the same as porting a W3DS platform. Use the guided port flow when an existing platform identity must remain intact.
+
+Continue with [Sign in and manage your account](./sign-in-and-account), [Create a new platform](./create-a-platform), or [Port an existing application](./port-an-existing-application).
+
+## Before you begin
+
+You need:
+
+- an eID wallet with a W3DS identity;
+- Git installed locally if you will clone or push code;
+- an SSH key or a GitW3 personal access token for command-line Git authentication; and
+- repository owner or organization permissions for actions such as PPA submission and migration activation.
+
+For application integration work, GitW3 can give a supported coding agent the current W3DS skill:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+The skill helps the agent use current protocol concepts and ontology identifiers. It does not replace review, tests, or secret handling.

docs/docs/GitW3/platform-manifest-and-workspace.md

@@ -0,0 +1,94 @@
+---
+sidebar_position: 6
+title: Platform manifest and W3DS workspace
+description: Understand .w3ds/platform.json, asynchronous publication, visibility, and the repository W3DS tab.
+---
+
+# Platform manifest and W3DS workspace
+
+Every GitW3 platform repository owns a manifest at `.w3ds/platform.json`. It is version-controlled platform metadata and the source from which GitW3 publishes the platform profile to W3DS.
+
+## Manifest shape
+
+A newly created platform starts with the following core fields:
+
+```json
+{
+ "schemaVersion": 1,
+ "platformName": "example-platform",
+ "displayName": "Example Platform",
+ "description": "A short description of the platform.",
+ "version": "0.1.0",
+ "ename": null,
+ "url": "https://example.invalid",
+ "logoUrl": "https://example.invalid/logo.png",
+ "domains": ["productivity", "work"],
+ "inSubmission": false,
+ "submissionVersion": "",
+ "isDraft": true
+}
+```
+
+Use real W3DS ontology domain identifiers from the GitW3 selector. The values above are illustrative.
+
+## Who controls each field
+
+| Field | Control and behavior |
+| --- | --- |
+| `schemaVersion` | Manifest format version. Do not change it without a supported schema migration. |
+| `platformName` | Stable machine-facing platform slug derived at creation. Immutable after identity creation. |
+| `displayName` | Human-facing name. Editable by permitted repository users. |
+| `description` | Human-facing platform description. |
+| `version` | Synchronized from the latest stable semantic GitW3 release; do not manually bump it. |
+| `ename` | Permanent platform eName. Initially `null`, then written by the publisher or preserved by the port flow. Immutable once assigned. |
+| `url` | Public application URL. Required for PPA submission. |
+| `logoUrl` | Optional public logo URL. |
+| `domains` | One or more supported W3DS application-domain identifiers. |
+| `inSubmission` | Whether the current release statement is in the PPA review flow. Managed by the signed application workflow. |
+| `submissionVersion` | Version associated with the current signed PPA submission. |
+| `isDraft` | Controls whether the synchronized platform profile is hidden from the public marketplace. |
+
+Migration and PPA workflows can add proof fields. Never fabricate, copy between platforms, or hand-edit cryptographic proof material.
+
+## The W3DS workspace
+
+Open a platform repository and select **W3DS**. The page is organized around the platform lifecycle:
+
+1. **Live publication status** reports the publisher's current state and latest result.
+2. **What happens next** tracks manifest, permanent identity, application URL, and stable release readiness.
+3. **Marketplace visibility** switches the profile between draft and published.
+4. **Platform details** edits the display name, description, domains, application URL, and logo URL.
+5. **PPA certificate** shows the requirement checklist, signed application, review conversation, and current decision.
+
+Repository or organization permissions control who may edit details, change visibility, apply for PPA, or activate a migration. Read-only visitors see the manifest-backed values without the edit controls.
+
+## Saving changes
+
+Saving through the W3DS workspace creates a normal commit on the default branch. GitW3 checks the last observed commit so it does not silently overwrite a newer manifest change.
+
+For changes made locally:
+
+1. Pull the latest default branch.
+2. Edit only supported, non-managed fields.
+3. Validate the JSON and domain identifiers.
+4. Commit and push normally.
+5. Open the **W3DS** tab and watch publication status.
+
+Do not manually change `platformName`, an assigned `ename`, release-controlled `version`, or signed proof fields.
+
+## Identity and publication are asynchronous
+
+After the initial manifest reaches the default branch, GitW3's publisher:
+
+- reserves and publishes the permanent platform eName;
+- provisions the platform eVault without an application key;
+- writes the assigned eName back to the manifest; and
+- synchronizes the platform profile and its visibility.
+
+Repository creation and Git pushes remain available while this happens. Temporary W3DS failures are retried; refresh the **W3DS** tab to see the current state. Repository administrators can see a detailed last error when intervention is required.
+
+The platform eName gets the platform eVault. Version eNames are Registry records for exact releases and do not create additional eVaults.
+
+## Draft versus published
+
+New platforms begin as drafts. A synchronized draft profile is hidden from the marketplace but still belongs to the repository. Use **Publish platform** in the W3DS workspace when the profile is ready to be discoverable; use **Make draft** to hide it again without deleting its stable identity.

docs/docs/GitW3/_category_.json

@@ -0,0 +1,8 @@
+{
+ "label": "GitW3",
+ "position": 1.5,
+ "link": {
+ "type": "generated-index",
+ "description": "Sign in, create or port a W3DS platform, publish releases, apply for PPA, and register deployments with GitW3."
+ }
+}

docs/docs/GitW3/create-a-platform.md

@@ -0,0 +1,79 @@
+---
+sidebar_position: 3
+title: Create a new platform
+description: Create a repository, initial W3DS manifest, and permanent platform identity with GitW3.
+---
+
+# Create a new platform
+
+Use **Make a new platform** when the application does not already have a W3DS platform identity. GitW3 creates the repository and initial manifest, then provisions the permanent platform eName asynchronously.
+
+From the **+** menu, select **New repository**, then choose **Make a new platform**.
+
+![The GitW3 choice between making a new platform and porting an existing application.](/img/gitw3/choose-platform-path.png)
+
+## Step 1: Repository
+
+Choose the owner and describe where the code will live:
+
+1. Select your user or an organization as **Owner**.
+2. Decide whether the repository is private.
+3. Enter the human-facing **Display name**.
+4. Confirm the default branch, normally `main`.
+
+![Step one of the create-platform wizard, where the owner and display name are selected.](/img/gitw3/new-platform-repository.png)
+
+You do not choose a repository slug. GitW3 derives a URL-safe repository name and the initial stable `platformName` from the display name. If that name is already used under the owner, GitW3 adds a numeric suffix safely.
+
+The display name can change later. Treat `platformName` as the permanent machine-facing identity; GitW3 will not change it when the friendly name changes.
+
+## Step 2: Platform details
+
+Enter the information W3DS needs to describe the platform:
+
+- **Description:** a concise explanation of what the platform does;
+- **Application domains:** one or more domains from the W3DS ontology;
+- **Application URL:** the public URL, if the application is already deployed; and
+- **Logo URL:** an optional public image URL.
+
+![Step two of the create-platform wizard, with a description, W3DS domains, application URL, and logo URL.](/img/gitw3/new-platform-details.png)
+
+The version is controlled by Git releases, not entered in this form. The initial version is `0.1.0` until a stable semantic release becomes the repository's published version.
+
+You can leave the application URL empty while building. It is required before applying for PPA.
+
+## Step 3: AI setup
+
+Choose whether GitW3 should show the quick install for the W3DS coding-agent skill.
+
+![Step three of the create-platform wizard, offering the W3DS skill command for supported coding agents.](/img/gitw3/new-platform-ai-setup.png)
+
+The command works with supported agents including Codex, Claude Code, Cursor, Copilot, and Windsurf:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+Select **Create platform**. GitW3 creates:
+
+- the repository;
+- an initial README;
+- `.w3ds/platform.json`; and
+- the first commit on the default branch.
+
+It does not create or expose a reusable platform private key. The permanent platform identity and its eVault are provisioned automatically without an application or deployment key.
+
+## After creation
+
+The welcome page shows the permanent eName as soon as publication completes. Keep the page open or return to the **W3DS** tab later; provisioning continues in the background.
+
+Next:
+
+1. Clone the repository and push the application code.
+2. Open the **W3DS** tab and confirm the manifest and identity status.
+3. Add the public application URL when the deployment is reachable.
+4. Publish a stable semantic release such as `v0.1.0`.
+5. Apply for a PPA certificate for that exact version.
+6. Register a deployment from the **Deploy** tab.
+
+See [The platform manifest and W3DS workspace](./platform-manifest-and-workspace) for the generated file and editable fields.

docs/docs/GitW3/deploy-a-release.md

@@ -0,0 +1,99 @@
+---
+sidebar_position: 8
+title: Register a deployment
+description: Create and sign a verifiable W3DS deployment record for a PPA-certified release.
+---
+
+# Register a deployment
+
+The GitW3 **Deploy** tab registers a verifiable W3DS deployment identity for a published release. It binds the exact code version, deployment environment, connected deployer, and a public application key.
+
+:::important
+
+This flow does not upload or run the application. Deploy the code with your normal hosting provider or pipeline, then use the generated key in that server or runtime when PP-Auth integration is available.
+
+:::
+
+## Prerequisites
+
+Before starting, confirm:
+
+- the platform eName is ready;
+- a stable semantic release is published;
+- PPA has granted a certificate for that exact version;
+- you are signed in with the eID wallet that will act as the deployer; and
+- the W3DS deployment publisher is available.
+
+Every deployment belongs to the connected deployer's eName. It does not claim that the platform authors or release committers operated the deployment.
+
+## Step 1: Choose release
+
+Open **Deploy** and select a PPA-certified release. The release binds the version tag and exact commit to the stable platform eName. Uncertified releases remain unavailable.
+
+You can register additional versions later without replacing earlier records.
+
+## Step 2: Describe deployment
+
+Enter a human-friendly name such as `Singapore production`, then choose an environment:
+
+- Production
+- Staging
+- Development
+- Custom
+
+These values distinguish multiple deployments of the same release. They do not configure a hosting region, DNS record, or deployment pipeline.
+
+## Step 3: Bind an application key
+
+Choose one of two key paths:
+
+### Generate a deployment key
+
+This is recommended for a first deployment. GitW3 generates an ECDSA P-256 key pair in the browser and downloads `w3ds-deployment-key.json` immediately. The backup uses the `w3ds-deployment-key-v1` format and contains:
+
+- algorithm metadata for ECDSA P-256 with SHA-256;
+- the `z`-prefixed public key;
+- the base64-encoded PKCS#8 private key; and
+- a creation timestamp.
+
+Confirm that the file was downloaded and stored safely before continuing.
+
+### Use an existing public key
+
+Choose this path when your runtime or secret manager already controls a compatible W3DS P-256 key. Paste only the `z`-prefixed public key. Do not upload or paste the private key into GitW3.
+
+:::danger The private key is shown only through the download
+
+GitW3 receives the public key and cannot recover the private key. Never commit `w3ds-deployment-key.json`, paste it into chat, expose it through an API, or ship it in a browser or mobile bundle.
+
+:::
+
+Store the private file in the hosting provider's secret manager or a read-only server mount. Prefer an environment variable such as `W3DS_DEPLOYMENT_KEY_FILE` that points to the mounted file instead of putting key material in an environment variable.
+
+## Step 4: Review and sign
+
+Review the release, deployment name, environment, deployer identity, and key handling confirmation. GitW3 reserves two identities:
+
+- a **deployment eName** bound to the deployment's public key and connected deployer; and
+- a **software-version eName** bound to the stable platform eName, release version, and exact Git commit.
+
+Select **Create identities and continue to wallet**, then scan or open the eID wallet. One wallet signature covers both documents. Nothing is provisioned until the signature is verified.
+
+## Publication and server integration
+
+The deployment card progresses through publishing, waiting for W3DS, published, or needs-attention states. After publication it shows both eNames and a **Use AI to configure the server** helper.
+
+That generated prompt contains the verified public deployment context but not the private key. It asks a coding assistant to:
+
+- inspect the existing server runtime and deployment method;
+- add a server-only loader for `w3ds-deployment-key-v1`;
+- validate P-256/SHA-256 and ensure the private key derives the expected public key;
+- keep key loading unreachable from client code;
+- use a secret manager or read-only mount; and
+- leave a narrow PP-Auth integration boundary without inventing an unpublished SDK or protocol.
+
+Keep the downloaded private-key file local when using that prompt. PP-Auth SDK integration is marked as coming soon in GitW3; do not invent a package name, endpoint, token format, or wire protocol.
+
+## Rotation and recovery
+
+If the private key is lost, GitW3 cannot restore it. Register a new deployment identity and update the server secret through a controlled rollout. Keep the old secret available only for the rollback window, verify the new public-key match at startup, then revoke or destroy the old secret according to your hosting policy.

docs/docs/GitW3/overview.md

@@ -0,0 +1,70 @@
+---
+sidebar_position: 1
+title: GitW3 overview
+description: Start here to understand GitW3 repositories, W3DS identities, releases, certification, and deployment records.
+---
+
+# GitW3 overview
+
+[GitW3](https://git.w3ds.metastate.foundation) is the W3DS-aware Git forge. It hosts source code and normal collaborative Git workflows, while connecting a platform repository to its permanent W3DS identity, published versions, PPA certificates, and verifiable deployment records.
+
+GitW3 is built around one rule: the repository is the source of truth for the platform metadata that W3DS publishes. The metadata lives beside the code in `.w3ds/platform.json`, and changes made from the GitW3 **W3DS** tab become ordinary commits on the default branch.
+
+## What GitW3 manages
+
+| Item | Meaning | Where you work with it |
+| --- | --- | --- |
+| Repository | Source code, issues, pull requests, tags, and releases | The regular repository tabs and Git |
+| Platform manifest | Version-controlled W3DS metadata | `.w3ds/platform.json` and the **W3DS** tab |
+| Platform eName | The permanent identity of the platform across releases | Provisioned automatically and shown on the **W3DS** tab |
+| Version eName | The identity of one exact released version | Derived from a stable Git release |
+| PPA certificate | Approval for one exact platform version | Apply and follow the review from the **W3DS** tab |
+| Deployment eName | A verifiable record of one running deployment | Created from the **Deploy** tab |
+
+The platform eName remains stable when the code, release, or deployment changes. Each released software version and each deployment receives its own identity so that W3DS records can refer to an exact artifact or running instance.
+
+:::important GitW3 records deployments; it does not host them
+
+The **Deploy** flow creates W3DS identities and attestations. Continue using your normal hosting provider or deployment pipeline to run the application.
+
+:::
+
+## The normal platform lifecycle
+
+```mermaid
+flowchart LR
+ A[Sign in with W3DS] --> B[Create or port a repository]
+ B --> C[Platform manifest committed]
+ C --> D[Permanent platform eName provisioned]
+ D --> E[Publish a stable release]
+ E --> F[Sign and submit PPA application]
+ F --> G[PPA certificate granted]
+ G --> H[Register and sign a deployment]
+```
+
+Identity and profile publication happen asynchronously. Git pushes and repository creation do not wait synchronously for every W3DS service. The status shown on the **W3DS** tab updates as the publisher completes or retries the work.
+
+## Choose the right starting path
+
+- **Make a new platform** creates a repository, an initial README, and `.w3ds/platform.json`. Use it when the application does not already have a W3DS identity.
+- **Port an existing app** creates an empty destination first. You then move the existing Git history and W3DS integration, transfer an existing eName if there is one, and explicitly activate the public cutover.
+- A regular code import is not the same as porting a W3DS platform. Use the guided port flow when an existing platform identity must remain intact.
+
+Continue with [Sign in and manage your account](./sign-in-and-account), [Create a new platform](./create-a-platform), or [Port an existing application](./port-an-existing-application).
+
+## Before you begin
+
+You need:
+
+- an eID wallet with a W3DS identity;
+- Git installed locally if you will clone or push code;
+- an SSH key or a GitW3 personal access token for command-line Git authentication; and
+- repository owner or organization permissions for actions such as PPA submission and migration activation.
+
+For application integration work, GitW3 can give a supported coding agent the current W3DS skill:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+The skill helps the agent use current protocol concepts and ontology identifiers. It does not replace review, tests, or secret handling.

docs/docs/GitW3/platform-manifest-and-workspace.md

@@ -0,0 +1,94 @@
+---
+sidebar_position: 6
+title: Platform manifest and W3DS workspace
+description: Understand .w3ds/platform.json, asynchronous publication, visibility, and the repository W3DS tab.
+---
+
+# Platform manifest and W3DS workspace
+
+Every GitW3 platform repository owns a manifest at `.w3ds/platform.json`. It is version-controlled platform metadata and the source from which GitW3 publishes the platform profile to W3DS.
+
+## Manifest shape
+
+A newly created platform starts with the following core fields:
+
+```json
+{
+ "schemaVersion": 1,
+ "platformName": "example-platform",
+ "displayName": "Example Platform",
+ "description": "A short description of the platform.",
+ "version": "0.1.0",
+ "ename": null,
+ "url": "https://example.invalid",
+ "logoUrl": "https://example.invalid/logo.png",
+ "domains": ["productivity", "work"],
+ "inSubmission": false,
+ "submissionVersion": "",
+ "isDraft": true
+}
+```
+
+Use real W3DS ontology domain identifiers from the GitW3 selector. The values above are illustrative.
+
+## Who controls each field
+
+| Field | Control and behavior |
+| --- | --- |
+| `schemaVersion` | Manifest format version. Do not change it without a supported schema migration. |
+| `platformName` | Stable machine-facing platform slug derived at creation. Immutable after identity creation. |
+| `displayName` | Human-facing name. Editable by permitted repository users. |
+| `description` | Human-facing platform description. |
+| `version` | Synchronized from the latest stable semantic GitW3 release; do not manually bump it. |
+| `ename` | Permanent platform eName. Initially `null`, then written by the publisher or preserved by the port flow. Immutable once assigned. |
+| `url` | Public application URL. Required for PPA submission. |
+| `logoUrl` | Optional public logo URL. |
+| `domains` | One or more supported W3DS application-domain identifiers. |
+| `inSubmission` | Whether the current release statement is in the PPA review flow. Managed by the signed application workflow. |
+| `submissionVersion` | Version associated with the current signed PPA submission. |
+| `isDraft` | Controls whether the synchronized platform profile is hidden from the public marketplace. |
+
+Migration and PPA workflows can add proof fields. Never fabricate, copy between platforms, or hand-edit cryptographic proof material.
+
+## The W3DS workspace
+
+Open a platform repository and select **W3DS**. The page is organized around the platform lifecycle:
+
+1. **Live publication status** reports the publisher's current state and latest result.
+2. **What happens next** tracks manifest, permanent identity, application URL, and stable release readiness.
+3. **Marketplace visibility** switches the profile between draft and published.
+4. **Platform details** edits the display name, description, domains, application URL, and logo URL.
+5. **PPA certificate** shows the requirement checklist, signed application, review conversation, and current decision.
+
+Repository or organization permissions control who may edit details, change visibility, apply for PPA, or activate a migration. Read-only visitors see the manifest-backed values without the edit controls.
+
+## Saving changes
+
+Saving through the W3DS workspace creates a normal commit on the default branch. GitW3 checks the last observed commit so it does not silently overwrite a newer manifest change.
+
+For changes made locally:
+
+1. Pull the latest default branch.
+2. Edit only supported, non-managed fields.
+3. Validate the JSON and domain identifiers.
+4. Commit and push normally.
+5. Open the **W3DS** tab and watch publication status.
+
+Do not manually change `platformName`, an assigned `ename`, release-controlled `version`, or signed proof fields.
+
+## Identity and publication are asynchronous
+
+After the initial manifest reaches the default branch, GitW3's publisher:
+
+- reserves and publishes the permanent platform eName;
+- provisions the platform eVault without an application key;
+- writes the assigned eName back to the manifest; and
+- synchronizes the platform profile and its visibility.
+
+Repository creation and Git pushes remain available while this happens. Temporary W3DS failures are retried; refresh the **W3DS** tab to see the current state. Repository administrators can see a detailed last error when intervention is required.
+
+The platform eName gets the platform eVault. Version eNames are Registry records for exact releases and do not create additional eVaults.
+
+## Draft versus published
+
+New platforms begin as drafts. A synchronized draft profile is hidden from the marketplace but still belongs to the repository. Use **Publish platform** in the W3DS workspace when the profile is ready to be discoverable; use **Make draft** to hide it again without deleting its stable identity.

docs/docs/GitW3/_category_.json

@@ -0,0 +1,8 @@
+{
+ "label": "GitW3",
+ "position": 1.5,
+ "link": {
+ "type": "generated-index",
+ "description": "Sign in, create or port a W3DS platform, publish releases, apply for PPA, and register deployments with GitW3."
+ }
+}

docs/docs/GitW3/create-a-platform.md

@@ -0,0 +1,79 @@
+---
+sidebar_position: 3
+title: Create a new platform
+description: Create a repository, initial W3DS manifest, and permanent platform identity with GitW3.
+---
+
+# Create a new platform
+
+Use **Make a new platform** when the application does not already have a W3DS platform identity. GitW3 creates the repository and initial manifest, then provisions the permanent platform eName asynchronously.
+
+From the **+** menu, select **New repository**, then choose **Make a new platform**.
+
+![The GitW3 choice between making a new platform and porting an existing application.](/img/gitw3/choose-platform-path.png)
+
+## Step 1: Repository
+
+Choose the owner and describe where the code will live:
+
+1. Select your user or an organization as **Owner**.
+2. Decide whether the repository is private.
+3. Enter the human-facing **Display name**.
+4. Confirm the default branch, normally `main`.
+
+![Step one of the create-platform wizard, where the owner and display name are selected.](/img/gitw3/new-platform-repository.png)
+
+You do not choose a repository slug. GitW3 derives a URL-safe repository name and the initial stable `platformName` from the display name. If that name is already used under the owner, GitW3 adds a numeric suffix safely.
+
+The display name can change later. Treat `platformName` as the permanent machine-facing identity; GitW3 will not change it when the friendly name changes.
+
+## Step 2: Platform details
+
+Enter the information W3DS needs to describe the platform:
+
+- **Description:** a concise explanation of what the platform does;
+- **Application domains:** one or more domains from the W3DS ontology;
+- **Application URL:** the public URL, if the application is already deployed; and
+- **Logo URL:** an optional public image URL.
+
+![Step two of the create-platform wizard, with a description, W3DS domains, application URL, and logo URL.](/img/gitw3/new-platform-details.png)
+
+The version is controlled by Git releases, not entered in this form. The initial version is `0.1.0` until a stable semantic release becomes the repository's published version.
+
+You can leave the application URL empty while building. It is required before applying for PPA.
+
+## Step 3: AI setup
+
+Choose whether GitW3 should show the quick install for the W3DS coding-agent skill.
+
+![Step three of the create-platform wizard, offering the W3DS skill command for supported coding agents.](/img/gitw3/new-platform-ai-setup.png)
+
+The command works with supported agents including Codex, Claude Code, Cursor, Copilot, and Windsurf:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+Select **Create platform**. GitW3 creates:
+
+- the repository;
+- an initial README;
+- `.w3ds/platform.json`; and
+- the first commit on the default branch.
+
+It does not create or expose a reusable platform private key. The permanent platform identity and its eVault are provisioned automatically without an application or deployment key.
+
+## After creation
+
+The welcome page shows the permanent eName as soon as publication completes. Keep the page open or return to the **W3DS** tab later; provisioning continues in the background.
+
+Next:
+
+1. Clone the repository and push the application code.
+2. Open the **W3DS** tab and confirm the manifest and identity status.
+3. Add the public application URL when the deployment is reachable.
+4. Publish a stable semantic release such as `v0.1.0`.
+5. Apply for a PPA certificate for that exact version.
+6. Register a deployment from the **Deploy** tab.
+
+See [The platform manifest and W3DS workspace](./platform-manifest-and-workspace) for the generated file and editable fields.

docs/docs/GitW3/deploy-a-release.md

@@ -0,0 +1,99 @@
+---
+sidebar_position: 8
+title: Register a deployment
+description: Create and sign a verifiable W3DS deployment record for a PPA-certified release.
+---
+
+# Register a deployment
+
+The GitW3 **Deploy** tab registers a verifiable W3DS deployment identity for a published release. It binds the exact code version, deployment environment, connected deployer, and a public application key.
+
+:::important
+
+This flow does not upload or run the application. Deploy the code with your normal hosting provider or pipeline, then use the generated key in that server or runtime when PP-Auth integration is available.
+
+:::
+
+## Prerequisites
+
+Before starting, confirm:
+
+- the platform eName is ready;
+- a stable semantic release is published;
+- PPA has granted a certificate for that exact version;
+- you are signed in with the eID wallet that will act as the deployer; and
+- the W3DS deployment publisher is available.
+
+Every deployment belongs to the connected deployer's eName. It does not claim that the platform authors or release committers operated the deployment.
+
+## Step 1: Choose release
+
+Open **Deploy** and select a PPA-certified release. The release binds the version tag and exact commit to the stable platform eName. Uncertified releases remain unavailable.
+
+You can register additional versions later without replacing earlier records.
+
+## Step 2: Describe deployment
+
+Enter a human-friendly name such as `Singapore production`, then choose an environment:
+
+- Production
+- Staging
+- Development
+- Custom
+
+These values distinguish multiple deployments of the same release. They do not configure a hosting region, DNS record, or deployment pipeline.
+
+## Step 3: Bind an application key
+
+Choose one of two key paths:
+
+### Generate a deployment key
+
+This is recommended for a first deployment. GitW3 generates an ECDSA P-256 key pair in the browser and downloads `w3ds-deployment-key.json` immediately. The backup uses the `w3ds-deployment-key-v1` format and contains:
+
+- algorithm metadata for ECDSA P-256 with SHA-256;
+- the `z`-prefixed public key;
+- the base64-encoded PKCS#8 private key; and
+- a creation timestamp.
+
+Confirm that the file was downloaded and stored safely before continuing.
+
+### Use an existing public key
+
+Choose this path when your runtime or secret manager already controls a compatible W3DS P-256 key. Paste only the `z`-prefixed public key. Do not upload or paste the private key into GitW3.
+
+:::danger The private key is shown only through the download
+
+GitW3 receives the public key and cannot recover the private key. Never commit `w3ds-deployment-key.json`, paste it into chat, expose it through an API, or ship it in a browser or mobile bundle.
+
+:::
+
+Store the private file in the hosting provider's secret manager or a read-only server mount. Prefer an environment variable such as `W3DS_DEPLOYMENT_KEY_FILE` that points to the mounted file instead of putting key material in an environment variable.
+
+## Step 4: Review and sign
+
+Review the release, deployment name, environment, deployer identity, and key handling confirmation. GitW3 reserves two identities:
+
+- a **deployment eName** bound to the deployment's public key and connected deployer; and
+- a **software-version eName** bound to the stable platform eName, release version, and exact Git commit.
+
+Select **Create identities and continue to wallet**, then scan or open the eID wallet. One wallet signature covers both documents. Nothing is provisioned until the signature is verified.
+
+## Publication and server integration
+
+The deployment card progresses through publishing, waiting for W3DS, published, or needs-attention states. After publication it shows both eNames and a **Use AI to configure the server** helper.
+
+That generated prompt contains the verified public deployment context but not the private key. It asks a coding assistant to:
+
+- inspect the existing server runtime and deployment method;
+- add a server-only loader for `w3ds-deployment-key-v1`;
+- validate P-256/SHA-256 and ensure the private key derives the expected public key;
+- keep key loading unreachable from client code;
+- use a secret manager or read-only mount; and
+- leave a narrow PP-Auth integration boundary without inventing an unpublished SDK or protocol.
+
+Keep the downloaded private-key file local when using that prompt. PP-Auth SDK integration is marked as coming soon in GitW3; do not invent a package name, endpoint, token format, or wire protocol.
+
+## Rotation and recovery
+
+If the private key is lost, GitW3 cannot restore it. Register a new deployment identity and update the server secret through a controlled rollout. Keep the old secret available only for the rollback window, verify the new public-key match at startup, then revoke or destroy the old secret according to your hosting policy.

docs/docs/GitW3/overview.md

@@ -0,0 +1,70 @@
+---
+sidebar_position: 1
+title: GitW3 overview
+description: Start here to understand GitW3 repositories, W3DS identities, releases, certification, and deployment records.
+---
+
+# GitW3 overview
+
+[GitW3](https://git.w3ds.metastate.foundation) is the W3DS-aware Git forge. It hosts source code and normal collaborative Git workflows, while connecting a platform repository to its permanent W3DS identity, published versions, PPA certificates, and verifiable deployment records.
+
+GitW3 is built around one rule: the repository is the source of truth for the platform metadata that W3DS publishes. The metadata lives beside the code in `.w3ds/platform.json`, and changes made from the GitW3 **W3DS** tab become ordinary commits on the default branch.
+
+## What GitW3 manages
+
+| Item | Meaning | Where you work with it |
+| --- | --- | --- |
+| Repository | Source code, issues, pull requests, tags, and releases | The regular repository tabs and Git |
+| Platform manifest | Version-controlled W3DS metadata | `.w3ds/platform.json` and the **W3DS** tab |
+| Platform eName | The permanent identity of the platform across releases | Provisioned automatically and shown on the **W3DS** tab |
+| Version eName | The identity of one exact released version | Derived from a stable Git release |
+| PPA certificate | Approval for one exact platform version | Apply and follow the review from the **W3DS** tab |
+| Deployment eName | A verifiable record of one running deployment | Created from the **Deploy** tab |
+
+The platform eName remains stable when the code, release, or deployment changes. Each released software version and each deployment receives its own identity so that W3DS records can refer to an exact artifact or running instance.
+
+:::important GitW3 records deployments; it does not host them
+
+The **Deploy** flow creates W3DS identities and attestations. Continue using your normal hosting provider or deployment pipeline to run the application.
+
+:::
+
+## The normal platform lifecycle
+
+```mermaid
+flowchart LR
+ A[Sign in with W3DS] --> B[Create or port a repository]
+ B --> C[Platform manifest committed]
+ C --> D[Permanent platform eName provisioned]
+ D --> E[Publish a stable release]
+ E --> F[Sign and submit PPA application]
+ F --> G[PPA certificate granted]
+ G --> H[Register and sign a deployment]
+```
+
+Identity and profile publication happen asynchronously. Git pushes and repository creation do not wait synchronously for every W3DS service. The status shown on the **W3DS** tab updates as the publisher completes or retries the work.
+
+## Choose the right starting path
+
+- **Make a new platform** creates a repository, an initial README, and `.w3ds/platform.json`. Use it when the application does not already have a W3DS identity.
+- **Port an existing app** creates an empty destination first. You then move the existing Git history and W3DS integration, transfer an existing eName if there is one, and explicitly activate the public cutover.
+- A regular code import is not the same as porting a W3DS platform. Use the guided port flow when an existing platform identity must remain intact.
+
+Continue with [Sign in and manage your account](./sign-in-and-account), [Create a new platform](./create-a-platform), or [Port an existing application](./port-an-existing-application).
+
+## Before you begin
+
+You need:
+
+- an eID wallet with a W3DS identity;
+- Git installed locally if you will clone or push code;
+- an SSH key or a GitW3 personal access token for command-line Git authentication; and
+- repository owner or organization permissions for actions such as PPA submission and migration activation.
+
+For application integration work, GitW3 can give a supported coding agent the current W3DS skill:
+
+```bash
+npx skills add MetaState-Prototype-Project/prototype@w3ds
+```
+
+The skill helps the agent use current protocol concepts and ontology identifiers. It does not replace review, tests, or secret handling.

docs/docs/GitW3/platform-manifest-and-workspace.md

@@ -0,0 +1,94 @@
+---
+sidebar_position: 6
+title: Platform manifest and W3DS workspace
+description: Understand .w3ds/platform.json, asynchronous publication, visibility, and the repository W3DS tab.
+---
+
+# Platform manifest and W3DS workspace
+
+Every GitW3 platform repository owns a manifest at `.w3ds/platform.json`. It is version-controlled platform metadata and the source from which GitW3 publishes the platform profile to W3DS.
+
+## Manifest shape
+
+A newly created platform starts with the following core fields:
+
+```json
+{
+ "schemaVersion": 1,
+ "platformName": "example-platform",
+ "displayName": "Example Platform",
+ "description": "A short description of the platform.",
+ "version": "0.1.0",
+ "ename": null,
+ "url": "https://example.invalid",
+ "logoUrl": "https://example.invalid/logo.png",
+ "domains": ["productivity", "work"],
+ "inSubmission": false,
+ "submissionVersion": "",
+ "isDraft": true
+}
+```
+
+Use real W3DS ontology domain identifiers from the GitW3 selector. The values above are illustrative.
+
+## Who controls each field
+
+| Field | Control and behavior |
+| --- | --- |
+| `schemaVersion` | Manifest format version. Do not change it without a supported schema migration. |
+| `platformName` | Stable machine-facing platform slug derived at creation. Immutable after identity creation. |
+| `displayName` | Human-facing name. Editable by permitted repository users. |
+| `description` | Human-facing platform description. |
+| `version` | Synchronized from the latest stable semantic GitW3 release; do not manually bump it. |
+| `ename` | Permanent platform eName. Initially `null`, then written by the publisher or preserved by the port flow. Immutable once assigned. |
+| `url` | Public application URL. Required for PPA submission. |
+| `logoUrl` | Optional public logo URL. |
+| `domains` | One or more supported W3DS application-domain identifiers. |
+| `inSubmission` | Whether the current release statement is in the PPA review flow. Managed by the signed application workflow. |
+| `submissionVersion` | Version associated with the current signed PPA submission. |
+| `isDraft` | Controls whether the synchronized platform profile is hidden from the public marketplace. |
+
+Migration and PPA workflows can add proof fields. Never fabricate, copy between platforms, or hand-edit cryptographic proof material.
+
+## The W3DS workspace
+
+Open a platform repository and select **W3DS**. The page is organized around the platform lifecycle:
+
+1. **Live publication status** reports the publisher's current state and latest result.
+2. **What happens next** tracks manifest, permanent identity, application URL, and stable release readiness.
+3. **Marketplace visibility** switches the profile between draft and published.
+4. **Platform details** edits the display name, description, domains, application URL, and logo URL.
+5. **PPA certificate** shows the requirement checklist, signed application, review conversation, and current decision.
+
+Repository or organization permissions control who may edit details, change visibility, apply for PPA, or activate a migration. Read-only visitors see the manifest-backed values without the edit controls.
+
+## Saving changes
+
+Saving through the W3DS workspace creates a normal commit on the default branch. GitW3 checks the last observed commit so it does not silently overwrite a newer manifest change.
+
+For changes made locally:
+
+1. Pull the latest default branch.
+2. Edit only supported, non-managed fields.
+3. Validate the JSON and domain identifiers.
+4. Commit and push normally.
+5. Open the **W3DS** tab and watch publication status.
+
+Do not manually change `platformName`, an assigned `ename`, release-controlled `version`, or signed proof fields.
+
+## Identity and publication are asynchronous
+
+After the initial manifest reaches the default branch, GitW3's publisher:
+
+- reserves and publishes the permanent platform eName;
+- provisions the platform eVault without an application key;
+- writes the assigned eName back to the manifest; and
+- synchronizes the platform profile and its visibility.
+
+Repository creation and Git pushes remain available while this happens. Temporary W3DS failures are retried; refresh the **W3DS** tab to see the current state. Repository administrators can see a detailed last error when intervention is required.
+
+The platform eName gets the platform eVault. Version eNames are Registry records for exact releases and do not create additional eVaults.
+
+## Draft versus published
+
+New platforms begin as drafts. A synchronized draft profile is hidden from the marketplace but still belongs to the repository. Use **Publish platform** in the W3DS workspace when the profile is ready to be discoverable; use **Make draft** to hide it again without deleting its stable identity.