api(title): rename to Sensitive Data Detector API

[jstjoe]

Summary

Rename the API title from "Privacy-detection API" to "Sensitive Data Detector API" across every user-facing surface of the published docs.

Files

• api/src/opf_api/main.py — FastAPI title= (source of truth)
• docs/api/openapi.json + docs/api/openapi.yaml — regenerated via uv run --package opf-api opf-api-export-openapi --out docs/api
• docs/index.html — browser <title> for the Scalar/Pages site
• docs/guides/overview.md — H1 of the overview guide

Out of scope

README.md, plans/06-unified-api.md, and plans/README.md reference "privacy-detection API" as historical/planning context — left as-is since they're not user-facing docs.

Test plan

• api/tests — 22/22 pass (with pytest-asyncio)
• Re-export OpenAPI from main.py and confirm both json + yaml carry the new title
• Reviewer: pull, run uvicorn opf_api.main:app, visit /scalar and confirm the rendered title

🤖 Generated with Claude Code

[jstjoe]

@claude review please?

[claude]

Claude finished @jstjoe's task in 1m 19s —— View job

---

PR Review

• Gather context
• Read changed files
• Provide review feedback

---

Overall: LGTM — clean, well-scoped rename. All 5 changed lines are consistent and correct. A few observations below.

Consistency check

All user-facing surfaces have been updated and are in sync:

Surface	Location	Status
FastAPI source of truth	api/src/opf_api/main.py:106	✅ Updated
OpenAPI JSON	docs/api/openapi.json:756	✅ Updated
OpenAPI YAML	docs/api/openapi.yaml:3	✅ Updated
Guide H1	docs/guides/overview.md:1	✅ Updated
Browser <title>	docs/index.html:6	✅ Updated

No stale references remain in user-facing files. The three intentional carve-outs (README.md, plans/README.md, plans/06-unified-api.md) still carry the old name as historical/planning context — that's a reasonable call and clearly documented in the PR body.

Minor observations (non-blocking)

1. No CI guard on generated artifacts. openapi.json and openapi.yaml are re-exported from main.py. If someone edits main.py and forgets to re-run opf-api-export-openapi, the generated files silently drift. Worth adding a CI step (opf-api-export-openapi --out /tmp/api && diff -r /tmp/api docs/api) eventually — not a blocker for this PR since the exports are visibly correct here.

2. summary field unchanged — "Unified PII detection across OPF, GLiNER, Presidio, and Skyflow." is fine as-is; just noting it doesn't reference the old title so nothing was missed there.

Manual verification step

The PR's test plan includes one unchecked item for the reviewer: pull, run uvicorn opf_api.main:app, visit /scalar and confirm the rendered title. The code changes are correct so this should pass, but worth doing before merging.

---

[jstjoe]

@claude I think we already have a CI job for ensuring "spec freshness" - is there a gap?

[claude]

Claude finished @jstjoe's task in 18s —— View job

---

• Check CI workflows for spec freshness coverage

---

You're right — the gap I flagged in my review is already closed. openapi.yml implements exactly the check I described:

# .github/workflows/openapi.yml
- name: Regenerate spec to a temp dir
  run: uv run --package opf-api opf-api-export-openapi --out /tmp/fresh

- name: Diff against committed spec
  run: |
    for f in openapi.json openapi.yaml; do
      if ! diff -u "docs/api/$f" "/tmp/fresh/$f"; then
        echo "::error file=docs/api/$f::$f is stale — regenerate with: ..."
        fail=1
      fi
    done

It triggers on any PR that touches api/** or docs/api/**, regenerates both files into a temp dir, and diffs against the committed copies — failing with a descriptive error if they diverge.

My earlier observation was incorrect. The CI guard exists and covers this PR. No gap.

---