Merge branch 'v1' into main

Bring PR #232 (website apex-domain + releasing.md reconcile) onto main and retire v1. main already carried PR #231 (v1.0 README refresh); this combines both doc lines.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: adamgell

.github/workflows/cmprojectx-docs.yml

@@ -4,14 +4,13 @@ name: "CMProjectX: Docs"
 # One-time setup: repo Settings → Pages → Source = "GitHub Actions".
 
 on:
-  # Auto-deploy is intentionally OFF while the docs are kept hidden.
-  # Publish manually from the Actions tab → "Run workflow" (workflow_dispatch),
-  # or un-comment the push trigger below to resume automatic publishing on merge.
-  # push:
-  #   branches: [main]
-  #   paths:
-  #     - "website/**"
-  #     - ".github/workflows/cmprojectx-docs.yml"
+  # Publishes intunecommander.com on every push to main that touches the site.
+  # (Manual runs are still available from the Actions tab via workflow_dispatch.)
+  push:
+    branches: [main]
+    paths:
+      - "website/**"
+      - ".github/workflows/cmprojectx-docs.yml"
   workflow_dispatch:
 
 permissions:

website/README.md

@@ -1,16 +1,16 @@
 # IntuneCommander documentation site
 
 Public docs for IntuneCommander, built with [Astro Starlight](https://starlight.astro.build) and
-deployed to GitHub Pages at **https://gellorg.github.io/intunecommander-src/**.
+deployed to GitHub Pages at **https://intunecommander.com**.
 
 ## Run it locally
 
 ```powershell
 npm install            # first time only
-npm run dev            # http://localhost:4321/intunecommander-src
+npm run dev            # http://localhost:4321/
 ```
 
-Before pushing, validate the production build under the real base path:
+Before pushing, validate the production build:
 
 ```powershell
 npm run build && npm run preview
@@ -30,9 +30,9 @@ scripts/redact.mjs     screenshot redaction + export tool
 
 - Pages live in `src/content/docs/`; the file path is the URL. Add a page, then list it in the
   `sidebar` in `astro.config.mjs`.
-- **Internal links:** write them root-absolute and base-less, e.g. `[Sign in](/sign-in/overview/)`.
-  A rehype plugin in `astro.config.mjs` adds the `/intunecommander-src` base at build time. (Hero `actions`
-  in `index.mdx` bypass Markdown, so the base is baked into those links by hand.)
+- **Internal links:** write them root-absolute, e.g. `[Sign in](/sign-in/overview/)`. The site is
+  served at the domain root (`base: '/'`), so these resolve as-is. (If the site ever moves to a
+  project Pages sub-path, the rehype plugin in `astro.config.mjs` prefixes the base at build time.)
 - **Components** (`<Steps>`, `<Tabs>`, `<Card>`, …) require an `.mdx` file; plain prose can be `.md`.
   Asides (`:::note`, `:::tip`, `:::caution`) work in both.
 

website/astro.config.mjs

@@ -4,10 +4,11 @@ import starlight from '@astrojs/starlight';
 import starlightLinksValidator from 'starlight-links-validator';
 
 // IntuneCommander documentation — Astro Starlight.
-// Project (not user) GitHub Pages site: served under /intunecommander-src.
-// NOTE: `base` is case-sensitive and must equal the GitHub repo name exactly
-// (the repo that hosts these Pages — the source repo, gellorg/intunecommander-src).
-const base = '/intunecommander-src';
+// Served at the apex custom domain https://intunecommander.com (GitHub Pages +
+// public/CNAME), so the site lives at the domain root and `base` is '/'.
+// (If this ever moves to a project Pages path, set `base` to '/<repo-name>' and
+// the rehypeBaseLinks helper below will start prefixing content links again.)
+const base = '/';
 
 /**
  * Prepend the site `base` to root-absolute internal links in Markdown/MDX content.
@@ -18,6 +19,9 @@ const base = '/intunecommander-src';
  * already-prefixed links.)
  */
 function rehypeBaseLinks() {
+	// At the domain root (`base === '/'`) there is nothing to prepend, and doing
+	// so would turn `/x` into `//x` (a protocol-relative link). No-op in that case.
+	if (base === '/') return () => {};
 	/** @param {any} node */
 	const walk = (node) => {
 		if (node.type === 'element' && node.tagName === 'a') {
@@ -40,7 +44,7 @@ function rehypeBaseLinks() {
 
 // https://astro.build/config
 export default defineConfig({
-	site: 'https://gellorg.github.io',
+	site: 'https://intunecommander.com',
 	base,
 	markdown: { rehypePlugins: [rehypeBaseLinks] },
 	integrations: [
@@ -54,7 +58,7 @@ export default defineConfig({
 				{
 					icon: 'github',
 					label: 'GitHub',
-					href: 'https://github.com/gellorg/intunecommander-release',
+					href: 'https://github.com/adamgell/IntuneCommander',
 				},
 			],
 			// Fail the build on broken internal links. The interactive Redoc page is a
@@ -65,7 +69,7 @@ export default defineConfig({
 					tag: 'meta',
 					attrs: {
 						property: 'og:image',
-						content: 'https://gellorg.github.io/intunecommander-src/og.png',
+						content: 'https://intunecommander.com/og.png',
 					},
 				},
 				{
@@ -77,7 +81,7 @@ export default defineConfig({
 					tag: 'meta',
 					attrs: {
 						name: 'twitter:image',
-						content: 'https://gellorg.github.io/intunecommander-src/og.png',
+						content: 'https://intunecommander.com/og.png',
 					},
 				},
 			],

website/public/CNAME

@@ -0,0 +1 @@
+intunecommander.com

website/src/content/docs/404.md

@@ -7,6 +7,6 @@ hero:
   tagline: That page wandered off — let's get you back on track.
   actions:
     - text: Back to the docs
-      link: /intunecommander-src/
+      link: /
       variant: primary
 ---

website/src/content/docs/changelog.md

@@ -16,4 +16,4 @@ _Prerelease._ First published build.
   audit/drift [time-machine](/using/time-machine/).
 - Bundled launcher (`Start-IntuneCommander.cmd`) starts the sidecar, then the client.
 
-[Release notes ›](https://github.com/gellorg/intunecommander-release/releases/tag/v0.1.0)
+[Release notes ›](https://github.com/adamgell/IntuneCommander/releases/tag/v0.1.0)

website/src/content/docs/develop/releasing.md

@@ -1,60 +1,75 @@
 ---
 title: Cutting a release
-description: How IntuneCommander releases are built and published — the repo layout and the local release script.
+description: How IntuneCommander releases are built, signed, and published — the tag-driven CI workflow, plus the local unsigned dev build.
 ---
 
-Releases are cut **locally** with a single PowerShell script. There is no GitHub Actions release
-workflow; the logic lives in one place a CI runner could also call.
+Official releases are cut by **CI**: push a `v<semver>` tag and the signed-release workflow builds,
+signs, and attaches the installers to a draft GitHub Release. A local script covers quick unsigned
+dev builds.
 
 ## Repo layout
 
-IntuneCommander lives in two repositories:
-
-| Repo | Visibility | Holds |
-| --- | --- | --- |
-| `gellorg/intunecommander-src` | private | the source (this repo + these docs) |
-| `gellorg/intunecommander-release` | private | published binaries + end-user docs (the [release channel](/get-started/download/)) |
+IntuneCommander is a single public repository —
+[`adamgell/IntuneCommander`](https://github.com/adamgell/IntuneCommander) — holding the source, these
+docs, and the published binaries on its [Releases](https://github.com/adamgell/IntuneCommander/releases)
+page (the [release channel](/get-started/download/)).
+
+## Cut a signed release (CI)
+
+The [**Signed Release (MSI + MSIX)**](https://github.com/adamgell/IntuneCommander/blob/main/.github/workflows/cmprojectx-codesign.yml)
+workflow is the source of truth. It runs on a version tag and produces a **signed MSI, a signed
+MSIX, and a portable zip for both `arm64` and `x64`**.
+
+1. **Match the version.** Set `[package] version` in `app/Cargo.toml` to the release version (no
+   leading `v`). CI fails fast if the tag and `Cargo.toml` disagree.
+2. **Tag and push.**
+
+   ```powershell
+   git tag v1.0.0-beta.1
+   git push origin v1.0.0-beta.1
+   ```
+
+   Or run it manually from **Actions → Signed Release → Run workflow** with a version — the workflow
+   creates the tag for you.
+3. **CI builds and signs.** For each architecture it builds the Rust/WinUI client, publishes the
+   self-contained .NET sidecar, bundles the pinned Maester modules, then packages a **signed MSI +
+   MSIX** with Master Packager Dev (Azure Trusted Signing) plus a portable zip. Build provenance is
+   attested.
+4. **Publish the draft.** CI attaches every asset to a **draft** GitHub Release — a `-beta.N` tag is
+   auto-marked *prerelease*. Review it and hit **Publish**.
+
+:::note[Release notes]
+Drop curated notes at `docs/release-notes/<tag>.md` (for example `docs/release-notes/v1.0.0-beta.1.md`)
+and CI uses them for the release body; otherwise it writes a one-line fallback.
+:::
 
-The build happens in the source repo; the artifacts are published to the release repo.
+:::caution[Signing & versions]
+Signing runs in the `codesigning` GitHub Environment. The Azure Trusted Signing identifiers are
+non-secret **variables**; only the client secret (and the optional `SYNCFUSION_LICENSE_KEY` for the
+Conditional Access → PowerPoint export) are secrets. Installer versions are 4-part numeric derived
+from the SemVer, so each beta cleanly upgrades the last — see
+[`packaging/README.md`](https://github.com/adamgell/IntuneCommander/blob/main/packaging/README.md).
+:::
 
-## The release script
+## Local dev build (unsigned)
 
-[`scripts/release.ps1`](https://github.com/gellorg/intunecommander-src/blob/main/scripts/release.ps1)
-(PowerShell 7+) is the "go script".
+For a quick local build without CI or signing,
+[`scripts/release.ps1`](https://github.com/adamgell/IntuneCommander/blob/main/scripts/release.ps1)
+(PowerShell 7+) builds the client + self-contained sidecar and stages a runnable, zipped bundle per
+architecture. Use `-DryRun` to keep the artifacts local — they land in `.\dist` and nothing is
+published:
 
 ```powershell
-# prerelease, x64 (the current target):
-.\scripts\release.ps1 -Version 0.2.0 -Arch x64
-
-# build + package only, no publish (artifacts land in .\dist):
-.\scripts\release.ps1 -Version 0.2.0 -Arch x64 -DryRun
-
-# stable (non-prerelease) release:
-.\scripts\release.ps1 -Version 1.0.0 -Arch x64 -Stable
+# both arches, unsigned, artifacts only (no GitHub release):
+.\scripts\release.ps1 -Version 1.0.0-beta.1 -DryRun
 ```
 
-For each architecture it:
+These builds are **unsigned** — use them for testing, not distribution. Signed, published releases
+always go through the CI workflow above.
 
-1. builds the Rust/WinUI client + `dotnet publish`es the sidecar (self-contained, no `.pdb`);
-2. stages a runnable bundle (`IntuneCommander.exe`, `sidecar\`, `docs\`, `Start-IntuneCommander.cmd`, `VERSION`) and zips it;
-3. publishes a GitHub Release `v<Version>` to the release repo with the zips attached
-   (`--prerelease` unless `-Stable`);
-4. syncs curated docs into the release repo.
-
-## Prerequisites
-
-- Run from a **full checkout**, not a git worktree — the Rust client has path dependencies on the
-  sibling `windows-rs` and `cmtraceopen` checkouts, which must sit next to the repo root.
-- An **x64 MSVC build environment** (Visual Studio Build Tools 2022 — enter the dev shell before
-  running) and the **.NET 10 preview SDK**.
-- An authenticated **`gh`** CLI.
-
-The script preflights all of this and stops with a clear message if something's missing.
-
-:::note[x64 only, for now]
-Builds currently target **win-x64**. ARM64 is the long-term primary target but needs the
-`aarch64-pc-windows-msvc` Rust target and the ARM64 VC tools installed first.
+:::note[Run from a full checkout]
+The Rust client has path dependencies on sibling `windows-rs` and `cmtraceopen` checkouts, which
+must sit next to the repo root — so build from a **full checkout, not a git worktree** (CI links
+these in automatically). You'll also need the **.NET 10 SDK** and the Rust toolchain with the
+`aarch64-pc-windows-msvc` / `x86_64-pc-windows-msvc` targets installed.
 :::
-
-Key flags: `-Arch x64`, `-SelfContained`, `-Notes <text|file>`, `-Stable`, `-DryRun`, `-Force`,
-`-SkipDocsSync`, `-ReleaseRepoPath <path>`.

website/src/content/docs/get-started/download.mdx

@@ -7,7 +7,7 @@ import { LinkButton } from '@astrojs/starlight/components';
 
 Most people don't need to build from source. Grab a prebuilt release, unzip it, and run.
 
-<LinkButton href="https://github.com/gellorg/intunecommander-release/releases" variant="primary" icon="external">
+<LinkButton href="https://github.com/adamgell/IntuneCommander/releases" variant="primary" icon="external">
 	Releases
 </LinkButton>
 

website/src/content/docs/get-started/install.mdx

@@ -15,9 +15,9 @@ Make sure you've installed everything on the [prerequisites](/get-started/prereq
    both repositories next to each other in the same parent folder:
 
    ```powershell
-   git clone https://github.com/gellorg/intunecommander-src
+   git clone https://github.com/adamgell/IntuneCommander
    git clone https://github.com/adamgell/cmtraceopen
-   cd intunecommander-src
+   cd IntuneCommander
    ```
 
 2. **Build the .NET sidecar.**
@@ -41,7 +41,7 @@ On a clean checkout, both the sidecar and the client compile without changes. Th
 
 :::note[Why two clones?]
 `app/` references the CMTrace Open parser through a local path that expects `cmtraceopen` to sit
-beside `intunecommander-src`. Keep them as siblings and the workspace build resolves it automatically.
+beside `IntuneCommander`. Keep them as siblings and the workspace build resolves it automatically.
 :::
 
 Next: [First run](/get-started/first-run/) →

website/src/content/docs/index.mdx

@@ -7,13 +7,13 @@ hero:
   image:
     file: ../../assets/cmx-mark.svg
   actions:
-    # Hero actions bypass Markdown, so the base path is baked in here (see astro.config.mjs).
+    # Hero actions bypass Markdown; links are root-absolute (site is served at the domain root).
     - text: Get started
-      link: /intunecommander-src/get-started/prerequisites/
+      link: /get-started/prerequisites/
       icon: right-arrow
       variant: primary
     - text: How sign-in works
-      link: /intunecommander-src/sign-in/overview/
+      link: /sign-in/overview/
       variant: minimal
 ---