Update to Clara

{
  "description": "Use when adding, changing, reviewing, or releasing a Clara workflow or hosted integration to record what Codex can read, every boundary beyond Codex, and the source-backed access and retention position before packaging.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 267
    },
    {
      "relative_path": "references/manifest-contract.md",
      "size_in_bytes": 2181
    },
    {
      "relative_path": "scripts/validate_privacy_surfaces.py",
      "size_in_bytes": 23426
    }
  ],
  "name": "privacy-surface-review",
  "skill_md_contents": "---\nname: privacy-surface-review\ndescription: Use when adding, changing, reviewing, or releasing a Clara workflow or hosted integration to record what Codex can read, every boundary beyond Codex, and the source-backed access and retention position before packaging.\n---\n\n<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->\nOnboarding is optional. Continue ordinary professional work immediately,\nincluding direct specialist invocation, without checking or completing a local\nonboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,\nor unavailable voice/window controls, must never block ordinary work. Do not\nautomatically start, resume or repeatedly offer onboarding.\nOnly for a user-requested tutorial or a native teaching handoff, read\n`../clara/references/local-onboarding.md`. A verified paired lesson worker\nexecutes only its bound lesson and token; never bypass tutorial validation.\nTutorial profiles, progress, examples and feedback remain local; never send a\nchange request, stamp a tutorial receipt or call hosted interviews for a tutorial.\nCurrent user requests take precedence over saved preferences.\n<!-- CLARA_OPENAI_ONBOARDING_END -->\n\n# Privacy Surface Review\n\nAfter substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.\n\nDo not initiate feedback merely because this release check was run.\n\nThis is a developer and release workflow. It is not a customer-case intake step.\nA normal Clara run does not display a privacy notice or ask for privacy consent\nmerely because Codex reads professional material.\n\n## Review workflow\n\n1. Resolve the Clara root and list every sibling directory in `skills/` that has\n   a `SKILL.md`. Every user-facing workflow except this review skill must have a\n   matching record in `privacy/workflows/`.\n2. Read the workflow's complete skill and every relevant script, reference,\n   payload builder, connector, browser route, and embedded component. For\n   Attribute Reporting and Brand Fit, resolve `modules/attribute-reporting` in a\n   packaged plugin or the sibling repository component.\n3. Record the information that may enter Codex context. Real client, participant,\n   employee, source, transcript, deck, and business data may enter that context.\n   Do not describe model-read material as local-only because its source file or\n   final artifact remains on the user's computer.\n   For ordinary Codex model processing, keep the common policy explicit: the\n   user-selected ChatGPT/Codex account is the processing arrangement; Clara adds\n   no separate recipient, does not automatically anonymise, and may filter or\n   aggregate locally only when useful. Clara cannot inspect or enforce the plan.\n4. Record every boundary beyond Codex in the workflow manifest. Link every\n   Mparanza route to one record in `privacy/hosted-services/`. Public research,\n   public image retrieval, external connectors, and send or publish actions stay\n   in the workflow manifest.\n5. For a hosted service, record only payload, access, and retention facts that\n   inspected governed source supports, including the relevant Mparanza service\n   and legal copy. If those sources do not establish hosted retention or\n   deletion, say so. Link expiry is not proof that stored material is deleted.\n6. The user's explicit choice of a hosted, connector, send, or publish route is\n   the confirmation for that route. Ask separately only when the external action\n   is optional and the user has not already chosen it. Do not ask twice.\n7. Record only source-enforced security controls and the user's ChatGPT/Codex\n   account boundary. An empty security-control array is accurate when the\n   workflow has no control of its own. Do not relabel local storage, output\n   review, source preservation, ordinary route choice, policy wording, or a\n   procedural instruction as security. Clara cannot inspect or enforce the\n   user's plan, model-training data controls, or retention/deletion controls. The\n   firm or user checks those before professional use and when the account or\n   terms change, not in a per-case form.\n8. Update the workflow and hosted-service manifests, then refresh only after the\n   substantive review is complete:\n\n```bash\npython skills/privacy-surface-review/scripts/validate_privacy_surfaces.py \\\n  --refresh <workflow-or-service-id>\n```\n\n9. Validate the complete register and run the Clara privacy tests before\n   packaging:\n\n```bash\npython skills/privacy-surface-review/scripts/validate_privacy_surfaces.py\npytest -q tests/plugins/test_clara_privacy_surfaces.py\n```\n\n## Judgment boundary\n\nUse deterministic code for registered-workflow coverage, JSON shape, allowed\nboundary kinds, hosted-service references, confirmation consistency, exact file\nhashing, and stale-review detection.\n\nDo not add automatic anonymisation, personal-data detection, deterministic\ndeletion, a `minimum useful context` classifier, per-prompt declarations, or\nroutine consent screens. Local Python may filter or aggregate information when\nthat improves the professional work; that is not a claim that everything read\nby Codex was anonymised.\n\nThis register is an engineering record. It is not legal advice, a DPIA, an\naccount-configuration audit, or a certification of GDPR compliance.\n\n## Codex-Native Run UX\n\nKeep a short developer checklist for workflow coverage, hosted-service coverage,\nsource review, fingerprint refresh, schema validation, and focused tests.\n\nBefore source review, show a compact Run Intake table with the changed workflow\nor service ID, governed paths, related manifests, and whether the change adds or\nalters a boundary beyond Codex. Show a Decision Table only when source evidence\nleaves a real boundary, access, or retention fact unresolved; record an unknown\ninstead of guessing.\n\nDefault output policy: update the affected manifest, refresh its fingerprint,\nand validate the complete register. These are not choices to propose when the\nuser asks for the normal privacy-surface review.\n\nBefore refreshing fingerprints, use one execution checkpoint naming the changed\nworkflow or service, governed paths, and manifests. Never edit generated ZIPs by\nhand; release artifacts are rebuilt from source.\n\nEnd with an Artifact Card listing the validated register, any intentionally\nunknown hosted arrangement, and the test result. Create `codex_run_review.md`\nonly when the review needs a local note about blocked source evidence, a schema\ngap, or repeated manual cleanup. Do not create customer-facing notices or case\nartifacts.\n"
}