chore(brand): em-dash sweep + scorecard publish_results fix

.github/workflows/scorecard.yml

@@ -5,7 +5,7 @@ on:
   schedule:
     - cron: '30 1 * * 1'  # Every Monday at 01:30 UTC
   push:
-    branches: [main]
+    branches: [main, develop]
   workflow_dispatch:
 
 permissions: read-all
@@ -29,7 +29,7 @@ jobs:
         with:
           results_file: results.sarif
           results_format: sarif
-          publish_results: ${{ github.ref == 'refs/heads/main' }}
+          publish_results: ${{ github.ref_name == github.event.repository.default_branch }}
 
       - uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
         with:
@@ -38,7 +38,7 @@ jobs:
           retention-days: 5
 
       - uses: github/codeql-action/upload-sarif@d4b3ca9fa7f69d38bfcd667bdc45bc373d16277e # v4
-        if: github.ref == 'refs/heads/main'
+        if: github.ref_name == github.event.repository.default_branch
         continue-on-error: true
         with:
           sarif_file: results.sarif

CHANGELOG.md

@@ -13,7 +13,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Philosophies: Branching Strategy, Release Cadence & Semver Discipline, Security Posture, Testing.
 - Workflows: Branching & Releases, CI Automation Surface.
 - Tooling: Development Tooling Stack (Claude Desktop for planning, Claude Code as primary execution, Cursor as supplemental).
-- Design notes: Claude Bot Account for AI-Authored PRs (design approved — Epsilon agent now active).
+- Design notes: Claude Bot Account for AI-Authored PRs (design approved. Epsilon agent now active).
 - Rendered overview diagrams under `docs/images/` for branching strategy, release cadence, and Claude Bot Account.
 - Release infrastructure: `VERSION`, `scripts/bump-version.sh`, `CHANGELOG.md`.
 - `CONTRIBUTING.md` rewritten for the handbook as canonical source for branching, commits, and releases across all repos.

CLAUDE.md

@@ -6,7 +6,7 @@ This file is read by Claude Code at the start of every session in this repo.
 
 ## About This Repo
 
-This is my personal engineering handbook — a documentation-primarily repo that captures the philosophies, workflows, and tooling that shape how I build software.
+This is my personal engineering handbook. A documentation-primarily repo that captures the philosophies, workflows, and tooling that shape how I build software.
 
 - Content lives in `docs/` as markdown files, with `README.md` acting as the landing page / table of contents.
 - There is no application code to lint, test, or build. Treat this repo as a writing project: prioritize clarity, consistency of voice, and structure.
@@ -27,7 +27,7 @@ This is my personal engineering handbook — a documentation-primarily repo that
 - **Branch model:** `main` = latest release. `develop` = integration branch.
 - Always branch from `develop`, never commit directly
 - PRs always target `develop`
-- `main` is only updated via CLI merge (`git merge --no-ff origin/develop`) by `/publish-release` — **never via a GitHub PR**. GitHub's merge button squash-merges by default, dropping ancestry and causing conflicts on the next release.
+- `main` is only updated via CLI merge (`git merge --no-ff origin/develop`) by `/publish-release`. **never via a GitHub PR**. GitHub's merge button squash-merges by default, dropping ancestry and causing conflicts on the next release.
 - Conventional commits: `feat:`, `fix:`, `docs:`, `chore:`
 
 ### Scripting Standards

CONTRIBUTING.md

@@ -1,33 +1,33 @@
 # Contributing to the Engineering Handbook
 
-This repo **is** the canonical source for branching strategy, commit convention, and release process — so this file is about contributing *to the handbook itself*, not a copy of the rules documented inside it.
+This repo **is** the canonical source for branching strategy, commit convention, and release process. So this file is about contributing *to the handbook itself*, not a copy of the rules documented inside it.
 
 For the rules, see:
 
-- [Branching Strategy philosophy](docs/philosophies/branching-strategy.md) — the *why*
-- [Branching & Releases workflow](docs/workflows/branching-and-releases.md) — the *how*
+- [Branching Strategy philosophy](docs/philosophies/branching-strategy.md). The *why*
+- [Branching & Releases workflow](docs/workflows/branching-and-releases.md). The *how*
 
 ---
 
 ## How to contribute
 
 This is a documentation repo, so the contribution model is the same as any other repo I own, just applied to prose instead of code.
 
-1. Branch from `develop` — `docs/<short-topic>` or `chore/<short-topic>` as appropriate.
+1. Branch from `develop`. `docs/<short-topic>` or `chore/<short-topic>` as appropriate.
 2. Edit existing chapters when possible; only add a new doc under `docs/` when a topic is substantial enough to stand alone.
-3. Commit with [Conventional Commits](https://www.conventionalcommits.org/) — most changes will be `docs:` or `chore:`.
+3. Commit with [Conventional Commits](https://www.conventionalcommits.org/). Most changes will be `docs:` or `chore:`.
 4. Open a PR targeting `develop`.
 5. CI (`Lint`, `Commit Lint`) must pass before merging.
 
 ## What belongs where
 
-- **Philosophies** (`docs/philosophies/`) — durable *why* content. Principles that justify decisions. Changes slowly.
-- **Workflows** (`docs/workflows/`) — concrete *how* content. Steps, commands, tooling. Changes as tools evolve.
-- **Tooling** (`docs/tooling/`) — what I use and how it fits together. Start at [`docs/tooling/dev-tooling-stack.md`](docs/tooling/dev-tooling-stack.md).
-- **Design notes** (`docs/design/`) — brainstorm-level proposals. Not polished specs.
+- **Philosophies** (`docs/philosophies/`). Durable *why* content. Principles that justify decisions. Changes slowly.
+- **Workflows** (`docs/workflows/`). Concrete *how* content. Steps, commands, tooling. Changes as tools evolve.
+- **Tooling** (`docs/tooling/`). What I use and how it fits together. Start at [`docs/tooling/dev-tooling-stack.md`](docs/tooling/dev-tooling-stack.md).
+- **Design notes** (`docs/design/`). Brainstorm-level proposals. Not polished specs.
 
 If a note is truly repo-specific (only applies to one project), it belongs in that repo, not here. If it applies to all my repos, it belongs here.
 
 ## Releases
 
-This repo uses the same release ceremony as every other repo I own — documented in the workflow doc linked above.
+This repo uses the same release ceremony as every other repo I own. Documented in the workflow doc linked above.

README.md

@@ -2,7 +2,7 @@
 
 # Alan's Engineering Handbook
 
-**How I build software — and the philosophies behind it.**
+**How I build software. And the philosophies behind it.**
 
 [![Validate](https://github.com/amcheste/engineering-handbook/actions/workflows/validate.yml/badge.svg)](https://github.com/amcheste/engineering-handbook/actions/workflows/validate.yml)
 [![Version](https://img.shields.io/github/v/tag/amcheste/engineering-handbook?label=version&sort=semver&color=0B0B0C)](https://github.com/amcheste/engineering-handbook/releases)
@@ -13,38 +13,38 @@
 
 ---
 
-This repo is my personal engineering handbook — the philosophies, workflows, and tooling that shape how I design, build, and ship software. It is written for myself first and shared publicly as a reference for anyone curious about how an engineer-first, AI-amplified practice actually works day to day.
+This repo is my personal engineering handbook. The philosophies, workflows, and tooling that shape how I design, build, and ship software. It is written for myself first and shared publicly as a reference for anyone curious about how an engineer-first, AI-amplified practice actually works day to day.
 
 It is a living document. Expect it to grow and change as my thinking evolves.
 
 ## Contents
 
 ### Philosophies
 
-The *why* — principles that explain the decisions behind how I work. These change slowly.
+The *why*. Principles that explain the decisions behind how I work. These change slowly.
 
-- [Branching Strategy](docs/philosophies/branching-strategy.md) — why every repo runs on `develop` / `main` with CLI-merged releases and conventional commits.
-- [Merge Strategy](docs/philosophies/merge-strategy.md) — why I rebase-merge PRs, never squash, and how that protects bot/human authorship.
-- [Release Cadence & Semver Discipline](docs/philosophies/release-cadence.md) — why releases are a deliberate ceremony, why the monthly patch cycle, and how conventional commits drive the version number.
-- [Security Posture](docs/philosophies/security-posture.md) — why every repo ships with the same SAST, Scorecard, CODEOWNERS, and SLA baseline from day one.
-- [Testing](docs/philosophies/testing.md) — why I write the tests I write, and why I don't write the ones I don't.
+- [Branching Strategy](docs/philosophies/branching-strategy.md). Why every repo runs on `develop` / `main` with CLI-merged releases and conventional commits.
+- [Merge Strategy](docs/philosophies/merge-strategy.md). Why I rebase-merge PRs, never squash, and how that protects bot/human authorship.
+- [Release Cadence & Semver Discipline](docs/philosophies/release-cadence.md). Why releases are a deliberate ceremony, why the monthly patch cycle, and how conventional commits drive the version number.
+- [Security Posture](docs/philosophies/security-posture.md). Why every repo ships with the same SAST, Scorecard, CODEOWNERS, and SLA baseline from day one.
+- [Testing](docs/philosophies/testing.md). Why I write the tests I write, and why I don't write the ones I don't.
 
 ### Workflows
 
-The *how* — concrete steps, commands, and tooling that implement the philosophies. These change as tools evolve.
+The *how*. Concrete steps, commands, and tooling that implement the philosophies. These change as tools evolve.
 
-- [Branching & Releases](docs/workflows/branching-and-releases.md) — branch model, day-to-day flow, and the release ceremony.
-- [CI Automation Surface](docs/workflows/ci-automation.md) — the GitHub Actions workflows that ship with every repo, what each does, and when it fires.
+- [Branching & Releases](docs/workflows/branching-and-releases.md). Branch model, day-to-day flow, and the release ceremony.
+- [CI Automation Surface](docs/workflows/ci-automation.md). The GitHub Actions workflows that ship with every repo, what each does, and when it fires.
 
 ### Development Tooling Stack
 
-- [Development Tooling Stack](docs/tooling/dev-tooling-stack.md) — the AI-assisted development stack I use, and the end-to-end workflows that run on top of it.
+- [Development Tooling Stack](docs/tooling/dev-tooling-stack.md). The AI-assisted development stack I use, and the end-to-end workflows that run on top of it.
 
 ### Design notes
 
-Brainstorm-level design docs capturing how I'm thinking about specific engineering problems. Not polished specs — working documents that evolve as decisions get made.
+Brainstorm-level design docs capturing how I'm thinking about specific engineering problems. Not polished specs. Working documents that evolve as decisions get made.
 
-- [Claude Bot Account for AI-Authored PRs](docs/design/claude-bot-account.md) — separating authorship from review so AI-written code has a clean audit trail.
+- [Claude Bot Account for AI-Authored PRs](docs/design/claude-bot-account.md). Separating authorship from review so AI-written code has a clean audit trail.
 
 _More chapters are in progress._