chore: document open-core model + parity manifest + CI warning

[govindkavaturi-art]

Summary

Docs + CI only. Zero code changes, zero behavior changes.

• HOSTED_ONLY.md — explains the open-core policy: what's intentionally hosted-only on cueapi.ai (billing, GDPR endpoints, blog pipeline, memory blocks, support-ticket routing, Jenny chatbot, deploy hook, dashboard UI, email alert delivery) and why.
• parity-manifest.json — enumerates the 60 files in app/ and alembic/ that have a same-path counterpart in the private cueapi monorepo, grouped by subdirectory. One file (app/services/email_service.py) is explicitly listed as OSS-only.
• .github/workflows/parity-check.yml — on each PR, intersects touched files with the manifest. If there are matches, posts (or updates-in-place) a comment asking the author to cross-reference the private repo. Never blocks merge — exits 0 unconditionally. Actions pinned to commit SHAs per the repo's security rules.
• README — new "Open core model" section near the top linking to HOSTED_ONLY.md.
• CHANGELOG — [Unreleased] entry.

What the parity-check comment looks like

When someone touches, say, app/services/outcome_service.py, the bot posts:

Parity check

This PR modifies files tracked in parity-manifest.json:

• app/services/outcome_service.py

Please confirm one of the following in a reply or PR description update:

1. The equivalent change has been applied to the private cueapi monorepo. Link the PR.
2. This change is OSS-only and does not need porting. Briefly explain why.
3. A follow-up issue has been filed to port the reverse direction. Link the issue.

This is a soft check — it does not block merge. The goal is visibility, not friction.

The comment is idempotent: on subsequent pushes to the PR, it updates in place (via a hidden marker) rather than spamming the thread.

Decisions

• Soft enforcement, not blocking. Blocking CI on cross-repo coordination would be friction for marginal gain; the goal is a visible nudge, not a gate. Maintainers can merge freely if they've already handled parity out of band.
• Manifest grouped by subdirectory. One flat list would be harder to skim. The workflow flattens across groups at runtime, so adding a new group (e.g. worker/ if that ever gets parity counterparts) just works.
• email_service.py excluded. It's OSS-only — private uses SendGrid via a different module layout. The manifest's oss_only_exclusions section documents this so future maintainers don't add it by reflex.
• Workflow uses actions/github-script for commenting rather than a third-party action, keeping the dependency surface minimal. SHA-pinned to v7.0.1.
• Fails-open on missing manifest. If someone ever renames or deletes parity-manifest.json, the workflow emits a ::notice:: and exits — it doesn't fail the PR.

Tests

None. This is docs + CI config.

• python3 -c "import json; json.load(open('parity-manifest.json'))" → OK
• python3 -c "import yaml; yaml.safe_load(open('.github/workflows/parity-check.yml'))" → OK

The workflow will self-exercise on this PR (which touches zero tracked files, so it should post no comment and log "No parity-tracked files modified").

Test plan

• Merge base branch; confirm workflow runs on future PRs
• Verify the workflow does NOT comment on this PR (it touches docs/CI only, nothing in the manifest)
• Verify a follow-up PR touching, e.g., app/models/cue.py triggers the comment
• Confirm that a re-push to that PR updates the comment in place rather than creating a second one

🤖 Generated with Claude Code

[argus-qa-ai]

All CI checks passing. Approved by Argus.