feat(build): add relative link rewriting and regenerate pages

- Add rewriteRelativeLinks to spec page generator for Astro-safe links
- Map assistant-adoption.md -> /assistants/ in generated pages
- Map schemas/assistant-adoption.schema.json -> GitHub blob URL
- Regenerate 13 spec pages and 5 assistant pages with all fixes

Author: zircote

scripts/generate-spec-pages.mjs

@@ -238,6 +238,21 @@ function rewriteLinks(content, crossReferences) {
   });
 }
 
+/**
+ * Rewrite relative file links using the relativeLinks map.
+ * Handles both plain paths and paths with anchors (e.g., file.md#section).
+ */
+function rewriteRelativeLinks(content, relativeLinks) {
+  if (!relativeLinks) return content;
+  return content.replace(/\]\(([^)#]+?)(#[^)]+)?\)/g, (match, path, anchor) => {
+    if (relativeLinks[path]) {
+      const target = relativeLinks[path];
+      return `](${target}${anchor || ""})`;
+    }
+    return match;
+  });
+}
+
 /**
  * Trim trailing whitespace from each line and ensure exactly one trailing newline.
  */
@@ -352,6 +367,7 @@ export function generateSpecPages(outputDir) {
 
     // Rewrite cross-page links
     body = rewriteLinks(body, config.crossReferences);
+    body = rewriteRelativeLinks(body, config.relativeLinks);
 
     // Build final file content
     const frontmatter = buildFrontmatter(page);

scripts/spec-mapping.json

@@ -118,5 +118,9 @@
     "#lockfile-format": "/specification/lockfile#lockfile-format",
     "#appendix-d-future-host-integration-targets": "/specification/appendices#appendix-d-future-host-integration-targets",
     "#supply-chain": "/specification/security#supply-chain"
+  },
+  "relativeLinks": {
+    "assistant-adoption.md": "/assistants/",
+    "schemas/assistant-adoption.schema.json": "https://github.com/zircote/ccpkg/blob/main/spec/schemas/assistant-adoption.schema.json"
   }
 }

src/content/docs/assistants/copilot-cli.mdx

@@ -103,3 +103,18 @@ command
 | Supported | true |
 | Transports | stdio |
 | Env Prefix | None |
+
+## Configuration
+
+| Scope | Path |
+|---|---|
+| user | `~/.copilot/settings.json` |
+| project | `.github/copilot-settings.json` |
+
+## Capabilities
+
+| Capability | Supported |
+|---|---|
+| Lazy Loading | false |
+| Hot Reload | false |
+| Managed Settings | false |

src/content/docs/assistants/gemini-cli.mdx

@@ -107,9 +107,16 @@ command
 | Property | Value |
 |---|---|
 | Supported | true |
-| Transports | stdio, sse, http-streaming |
+| Transports | stdio, sse, streamable-http |
 | Env Prefix | None |
 
+## Configuration
+
+| Scope | Path |
+|---|---|
+| user | `~/.gemini/settings.json` |
+| project | `.gemini/settings.json` |
+
 ## Capabilities
 
 | Capability | Supported |

src/content/docs/specification/component-types.mdx

@@ -203,7 +203,7 @@ ccpkg defines a canonical (tool-neutral) event vocabulary for portable hook defi
 | `pre-compact` | Before context/history compression |
 | `user-prompt-submit` | When user submits a prompt |
 
-Not all hosts support all canonical events. The mapping from canonical names to host-native event names is defined in each host's [adoption specification](assistant-adoption.md#hook-event-mappings). Hosts MAY also define additional events beyond the canonical vocabulary; these are documented in the host's adoption spec.
+Not all hosts support all canonical events. The mapping from canonical names to host-native event names is defined in each host's [adoption specification](/assistants/#hook-event-mappings). Hosts MAY also define additional events beyond the canonical vocabulary; these are documented in the host's adoption spec.
 
 **Usage rules:**
 

src/content/docs/specification/install-lifecycle.mdx

@@ -85,7 +85,7 @@ sequenceDiagram
 
 12. **Generate host plugin manifest.** The installer generates the host's expected plugin manifest inside the install directory from the ccpkg manifest metadata. The manifest path and format are defined in the host's adoption specification. See [Plugin Registration](/specification/install-lifecycle#plugin-registration) for details.
 
-13. **Register with host.** The installer registers the package with the host's extension system using the adapter operations defined in the host's [adoption specification](assistant-adoption.md). This ensures the host discovers the package on next session start.
+13. **Register with host.** The installer registers the package with the host's extension system using the adapter operations defined in the host's [adoption specification](/assistants/). This ensures the host discovers the package on next session start.
 
 14. **Update lockfile.** The installer writes or updates `ccpkg-lock.json` at the scope root (e.g., `~/.ccpkg/ccpkg-lock.json` for user scope). See [Lockfile Format](/specification/lockfile#lockfile-format).
 
@@ -152,21 +152,21 @@ For quick one-off testing without any persistent side effects, developers can us
 
 # Host Integration
 
-ccpkg integrates with each host's extension or plugin system, leveraging the host's runtime for component registration and namespace isolation. The specific integration mechanism is defined in each host's [adoption specification](assistant-adoption.md).
+ccpkg integrates with each host's extension or plugin system, leveraging the host's runtime for component registration and namespace isolation. The specific integration mechanism is defined in each host's [adoption specification](/assistants/).
 
 ## Bootstrap
 
-On first use, ccpkg registers itself with the host's extension discovery system. The bootstrap process varies by host — some use marketplace registration, others use directory scanning or plugin manifests. The exact mechanism is defined in the host's adoption specification under `plugin_model`.
+On first use, ccpkg registers itself with the host's extension discovery system. The bootstrap process varies by host — some use marketplace registration, others use directory scanning or plugin manifests. The exact mechanism is defined in the host's adoption specification under `extension_model`.
 
 ## Plugin Registration
 
 During installation, the installer performs two host-facing steps as defined by the host's adoption specification:
 
-1. **Generate host plugin manifest.** The installer creates the host's expected plugin manifest inside the install directory, mapping ccpkg manifest fields (name, version, description, author) to the host's manifest format. The manifest path and format are defined in the host's `plugin_model.manifest_path` field. Package authors SHOULD NOT include host-specific plugin manifests in their archives. If a host-specific manifest is present, the installer MUST use the generated version and MAY warn the author.
+1. **Generate host plugin manifest.** The installer creates the host's expected plugin manifest inside the install directory, mapping ccpkg manifest fields (name, version, description, author) to the host's manifest format. The manifest path and format are defined in the host's `extension_model.manifest.filename` field. Package authors SHOULD NOT include host-specific plugin manifests in their archives. If a host-specific manifest is present, the installer MUST use the generated version and MAY warn the author.
 
-2. **Register with host.** The installer registers the package with the host's extension system as described in the host's `adapter_interface` operations. This ensures the host recognizes the package on the next session start.
+2. **Register with host.** The installer registers the package with the host's extension system as described in the host's `extension_model.registration` mechanism. This ensures the host recognizes the package on the next session start.
 
-These two steps — generating a plugin manifest and registering with the host — are the complete integration surface. The specific files and settings keys are defined in each host's [adoption specification](assistant-adoption.md).
+These two steps — generating a plugin manifest and registering with the host — are the complete integration surface. The specific files and settings keys are defined in each host's [adoption specification](/assistants/).
 
 ## Namespacing
 
@@ -178,7 +178,7 @@ For example, a package named `api-testing` containing `skills/run-suite/` expose
 
 ## Scope and Settings
 
-Each installation scope maps to a different host settings location. The specific paths vary by host and are defined in the host's [adoption specification](assistant-adoption.md) under `configuration.settings_paths`.
+Each installation scope maps to a different host settings location. The specific paths vary by host and are defined in the host's [adoption specification](/assistants/) under `configuration.settings_paths`.
 
 | Scope | Plugin Directory | Behavior |
 |---|---|---|

src/content/docs/specification/manifest.mdx

@@ -126,7 +126,7 @@ The `compatibility` object declares version constraints for host tools. Each key
 }
 ```
 
-Keys are host identifiers as defined in individual [adoption specifications](assistant-adoption.md). Installers SHOULD warn the user if the host does not satisfy the declared compatibility constraint. Installers MUST NOT refuse installation solely based on an unrecognized tool identifier.
+Keys are host identifiers as defined in individual [adoption specifications](/assistants/). Installers SHOULD warn the user if the host does not satisfy the declared compatibility constraint. Installers MUST NOT refuse installation solely based on an unrecognized tool identifier.
 
 ## Targets Object
 
@@ -156,7 +156,7 @@ The following standard fields are defined. Tool-specific adapters MAY define add
 }
 ```
 
-Each key is a host identifier matching an [adoption specification](assistant-adoption.md). The `hook_events` mapping translates canonical event names to host-native event names; the `instructions_file` declares the filename to which assembled instructions are written. Missing canonical events in a host's `hook_events` mean the host has no equivalent — hooks using those canonical names are silently skipped on that host. See individual adoption specs for the complete event mappings, instruction filenames, and MCP prefixes for each host.
+Each key is a host identifier matching an [adoption specification](/assistants/). The `hook_events` mapping translates canonical event names to host-native event names; the `instructions_file` declares the filename to which assembled instructions are written. Missing canonical events in a host's `hook_events` mean the host has no equivalent — hooks using those canonical names are silently skipped on that host. See individual adoption specs for the complete event mappings, instruction filenames, and MCP prefixes for each host.
 
 ## Example Manifest
 

src/content/docs/specification/overview.mdx

@@ -5,7 +5,7 @@ description: "Introduction to the ccpkg specification, design principles, and ar
 
 # ccpkg Specification
 
-**Specification Version: 2026-02-14 (Draft)**
+**Specification Version: 2026-02-22 (Draft)**
 
 ## Status
 
@@ -115,6 +115,6 @@ stateDiagram-v2
 
 The ccpkg specification is structured as a layered system. This core specification defines the universal packaging format — archive structure, manifest schema, component types, install lifecycle, and security model. It is intentionally tool-agnostic: no host-specific filenames, settings paths, or plugin registration mechanisms appear in the core spec.
 
-Host-specific integration details are captured in **assistant adoption specifications**, one per AI coding assistant. Each adoption spec declares how ccpkg maps to a particular host's conventions: instruction filenames, hook event names, plugin registration steps, settings paths, and component support levels. Adoption specs are machine-validated against the [Assistant Adoption Specification Schema](schemas/assistant-adoption.schema.json) and published alongside this specification in the `spec/assistants/` directory.
+Host-specific integration details are captured in **assistant adoption specifications**, one per AI coding assistant. Each adoption spec declares how ccpkg maps to a particular host's conventions: instruction filenames, hook event names, plugin registration steps, settings paths, and component support levels. Adoption specs are machine-validated against the [Assistant Adoption Specification Schema](https://github.com/zircote/ccpkg/blob/main/spec/schemas/assistant-adoption.schema.json) and published alongside this specification in the `spec/assistants/` directory.
 
-The [Assistant Adoption Specification](assistant-adoption.md) defines the normative contract for what an adoption spec MUST contain. Installers use adoption specs at install time to perform host-specific adapter operations (generating plugin manifests, registering with the host, translating hook events). Package authors consult adoption specs to understand which components each host supports and how to structure portable packages.
+The [Assistant Adoption Specification](/assistants/) defines the normative contract for what an adoption spec MUST contain. Installers use adoption specs at install time to perform host-specific adapter operations (generating plugin manifests, registering with the host, translating hook events). Package authors consult adoption specs to understand which components each host supports and how to structure portable packages.

src/content/docs/specification/portability.mdx

@@ -20,7 +20,7 @@ The following components are tool-agnostic and work across any host that support
 
 ## Component Portability Matrix
 
-The portability status of each component type is documented in each host's [adoption specification](assistant-adoption.md) under `component_support`. Consult the relevant adoption spec to determine which components a host supports and at what level.
+The portability status of each component type is documented in each host's [adoption specification](/assistants/) under `component_support`. Consult the relevant adoption spec to determine which components a host supports and at what level.
 
 **Support levels:**
 - **Native**: Component type is natively supported by the host
@@ -49,7 +49,7 @@ Four mechanisms handle tool-specific differences:
 - Prefer MCP for tool integration over host-specific mechanisms.
 - Use `compatibility` to declare minimum host versions rather than excluding hosts.
 - Use per-component `hosts` scoping for host-specific hooks or agents alongside universal skills.
-- Use canonical event names for hook portability. Consult each host's [adoption specification](assistant-adoption.md) for supported events.
+- Use canonical event names for hook portability. Consult each host's [adoption specification](/assistants/) for supported events.
 - Scope agents to specific hosts via `hosts` — agent formats are not yet portable across hosts.
 - Scope LSP components to hosts that support them. Check each host's `component_support.lsp_servers` in its adoption spec.
 - When a host requires an MCP environment variable prefix, declare it via `targets.{host}.mcp_env_prefix`. See the host's adoption spec for the specific prefix value.