@soleur/opencode 0.0.0-stage → 3.354.2

package/skills/gdpr-gate/references/leakage-vectors.md

@@ -0,0 +1,248 @@
+<!-- Adapted from gosprinto/compliance-skills (MIT) — see NOTICE -->
+# PII Leakage Vectors
+
+Loaded during repo scan only. These are the places PII most commonly
+leaks in production — outside of models and schemas.
+
+---
+
+## V-01: Logging (Highest Frequency)
+
+What to grep:
+```
+console.log(       console.error(     console.info(
+logger.info(       logger.debug(      logger.warn(      logger.error(
+
+# JavaScript / Node
+winston.           bunyan.            Timber.log(
+
+# Python
+print(             logging.info(      logging.debug(     logging.warning(
+logger.info(       logger.debug(      log.info(
+
+# Ruby / Rails
+Rails.logger.      logger.info        logger.debug       puts
+
+# Go
+log.Printf(        log.Println(       fmt.Println(       fmt.Printf(
+zap.               logrus.
+
+# Java / Kotlin
+System.out.print(  log.info(          logger.info(       Logger.getLogger(
+Timber.log(
+```
+
+Flag when:
+- Full objects logged: `console.log(user)`, `logger.info(req.body)`
+- PII field names near log call: `logger.debug("email:", user.email)`
+- Request/response bodies logged in middleware
+
+Fix pattern:
+```javascript
+// Wrong
+console.log('User updated:', user)
+logger.info(req.body)
+
+// Right
+console.log('User updated:', user.id)          // log ID only
+logger.info({ action: 'user_updated', userId: user.id })
+```
+
+---
+
+## V-02: Error Handling (Second Most Common)
+
+What to grep:
+```
+catch (          except:          rescue
+.catch(          on_error         rescue =>
+error.message    err.toString()   JSON.stringify(error)
+res.status(500).json(    render json: e    raise
+```
+
+Flag when:
+- Raw error objects returned to client: `res.json({ error: err })`
+- Stack traces exposed: `res.send(err.stack)`
+- Request body in error response: `res.json({ error: e, input: req.body })`
+
+Fix pattern:
+```javascript
+// Wrong
+app.use((err, req, res, next) => {
+  res.status(500).json({ error: err.message, stack: err.stack })
+})
+
+// Right
+app.use((err, req, res, next) => {
+  logger.error({ errorId: uuid(), message: err.message }) // log server-side only
+  res.status(500).json({ error: 'Something went wrong', errorId })
+})
+```
+
+---
+
+## V-03: Analytics / Tracking
+
+What to grep:
+```
+mixpanel.track(    amplitude.track(    analytics.track(
+segment.identify(  heap.identify(      posthog.capture(
+gtag(              fbq(                _hsq.push(
+rudderstack.       braze.              klaviyo.
+```
+
+Flag when:
+- PII passed as event properties: `track('Signup', { email, phone })`
+- Full user object in identify: `identify(userId, { ...user })`
+- Health or financial data in any analytics call
+
+Fix pattern:
+```javascript
+// Wrong
+mixpanel.track('Purchase', { email: user.email, card_last4, amount })
+
+// Right
+mixpanel.track('Purchase', { userId: user.id, amount })  // no PII in events
+```
+
+---
+
+## V-04: Caching
+
+What to grep:
+```
+redis.set(         redis.setex(       cache.set(
+Rails.cache.write( memcache.set(      client.set(
+Cache.put(         CacheManager.
+```
+
+Flag when:
+- PII cached without TTL: `redis.set('user:123', JSON.stringify(user))`
+- Full user object cached: includes email, phone, sensitive fields
+- No encryption on cached PII
+
+Fix pattern:
+```javascript
+// Wrong
+redis.set(`user:${id}`, JSON.stringify(user))
+
+// Right
+redis.setex(`user:${id}`, 3600, JSON.stringify({
+  id: user.id,
+  name: user.name   // only cache what's needed, set TTL
+}))
+```
+
+---
+
+## V-05: External API Calls
+
+What to grep:
+```
+fetch(             axios.post(        axios.get(
+requests.post(     http.Post(         HTTParty.post(
+RestClient.post(   urllib.request(    curl
+```
+
+Flag when:
+- PII fields in request body to third-party URLs
+- Full user object forwarded to external service
+- Sensitive data in query parameters (visible in logs)
+
+Fix pattern:
+```javascript
+// Wrong
+await axios.post('https://api.vendor.com/users', {
+  email: user.email, ssn: user.ssn, dob: user.dob
+})
+
+// Right — send only what vendor actually needs
+await axios.post('https://api.vendor.com/users', {
+  externalId: user.id,
+  verified: true
+})
+```
+
+---
+
+## V-06: API Responses / Serializers
+
+What to grep:
+```
+res.json(user      render json: @user    jsonify(user)
+to_json            as_json               serialize
+JSON.stringify(user  toJSON(            transform(user
+```
+
+Flag when:
+- Full model returned: `res.json(user)` — includes all fields
+- `password_hash` included in response
+- SSN, health fields, or financial data in response body
+- `SELECT *` used in query feeding into response
+
+Fix pattern:
+```javascript
+// Wrong
+res.json(user)
+
+// Right
+res.json({
+  id: user.id,
+  name: user.name,
+  email: user.email
+  // password_hash, ssn, dob excluded explicitly
+})
+```
+
+---
+
+## V-07: File / Object Storage
+
+What to grep:
+```
+s3.upload(         s3.putObject(      bucket.file(
+fs.writeFile(      fs.appendFile(     open(filename, 'w')
+Storage.upload(    blob.upload(       writeStream(
+```
+
+Flag when:
+- PII written to unencrypted local files
+- S3 bucket ACL not set to private
+- No server-side encryption on S3 uploads
+- Export files (CSV, JSON) containing PII stored without encryption
+
+Fix pattern:
+```javascript
+// Wrong
+s3.putObject({ Bucket: 'exports', Key: 'users.csv', Body: csvData })
+
+// Right
+s3.putObject({
+  Bucket: 'exports',
+  Key: 'users.csv',
+  Body: csvData,
+  ServerSideEncryption: 'AES256',
+  ACL: 'private'
+})
+```
+
+---
+
+## V-08: Config / Environment Files
+
+What to grep:
+```
+.env               .env.example       config/database.yml
+seed.rb            seeds.js           fixtures/
+hardcoded @        hardcoded phone    hardcoded SSN
+```
+
+Flag when:
+- Real email addresses, phone numbers, SSNs in seed/fixture files
+- PII in `.env.example` (often committed to git)
+- Real credentials or PII in any committed config file
+
+Fix:
+- Replace with obviously fake data: `user@example.com`, `555-0100`, `000-00-0000`
+- Add `.env` to `.gitignore` if not already present
+- Audit git history for accidentally committed PII (use `git-secrets` or `truffleHog`)

package/skills/gdpr-gate/references/legacy/legal-consent-v1-prose.md

@@ -0,0 +1,48 @@
+<!-- Archived v1 prose-shape — preserved for one release cycle for regulatory-citation provenance. Will be removed at v3. -->
+
+# Legal consent — ePrivacy + GDPR Art. 7 / 13 / 14 / 35
+
+Written from scratch for Soleur. Consent and disclosure flows that the gate checks at design time. Output is advisory; the load-bearing enforcement is in the privacy policy + cookie banner + DPIA docs (`legal-audit` and `legal-generate` skills handle the document side).
+
+## ePrivacy Directive (2002/58/EC) — cookie consent
+
+The ePrivacy Directive predates GDPR but governs storage and access to information on terminal equipment (cookies, localStorage, IndexedDB, fingerprinting).
+
+What the gate checks at plan time:
+- Plan prose introducing analytics, A/B-testing, advertising, or cross-site tracking → check for a cookie-consent precondition (`Suggestion` if missing).
+- Plan prose introducing a cookie banner → check it implements opt-IN (consent before set), not opt-OUT (set first, ask later) — opt-out cookie banners are non-compliant in EEA.
+
+## Art. 7 — Conditions for consent
+- Consent must be **freely given, specific, informed, unambiguous**.
+- Withdrawal must be **as easy as giving** consent.
+- Consent for special-category processing under Art. 9(2)(a) must be **explicit**.
+
+What the gate checks: schema additions for `consent_given`, `terms_accepted_at`, `privacy_accepted_at` columns flag a `Suggestion` reminder to verify the UX matches Art. 7 ("freely given" rules out pre-checked boxes; "specific" rules out catch-all consent).
+
+## Art. 13 + 14 — Information to be provided
+
+Art. 13 (data collected from the subject) and Art. 14 (data collected from third parties) require disclosure of:
+- Identity + contact of the controller
+- DPO contact (if applicable)
+- Purposes + lawful basis
+- Recipients / categories of recipients
+- Cross-border transfer destinations + safeguards
+- Retention periods
+- Data subject rights (access, rectification, erasure, restriction, portability, objection, withdrawal of consent, complaint to supervisory authority)
+- Source (Art. 14 only)
+
+What the gate checks: new schema columns / new vendor SDKs route to a one-liner reminder to update the privacy policy. The actual policy content lives in `legal-audit`.
+
+## Art. 35 — Data Protection Impact Assessment (DPIA)
+
+Required when processing is **likely to result in high risk** to data subjects. Indicators:
+- Systematic + extensive automated evaluation (Art. 22 profiling).
+- Large-scale special-category processing (Art. 9 columns + production scale).
+- Systematic monitoring of public space.
+
+What the gate checks: plan-time prose introducing one of the indicators surfaces a DPIA-required note. The DPIA template lives outside this skill.
+
+## Boundary with other skills
+- **legal-audit**: scans existing policy / terms / cookie / DPA documents for compliance gaps.
+- **legal-generate**: drafts new legal documents.
+- **gdpr-gate**: scans diffs and plans for design-time signals that demand a legal-audit / legal-generate follow-up.

package/skills/gdpr-gate/references/legal-consent.md

@@ -0,0 +1,140 @@
+<!-- Soleur-authored — see NOTICE -->
+
+# Layer: Legal Consent (ePrivacy + GDPR Art. 7 / 13 / 14 / 35)
+
+## When This Layer Loads
+
+Auto-trigger inline when the gate is about to evaluate:
+
+- Cookie banner code, consent UI, or any `consent` / `optIn` / `optOut` columns or fields
+- A privacy notice, cookie policy, or terms-of-service text change
+- A new third-party SDK / pixel / analytics integration
+- A schema column whose name matches the Art. 9 special-category list (`fields.md`)
+- A new automated-decision or profiling code path (Art. 22)
+- A diff that touches `apps/web-platform/lib/auth/consent`, `apps/web-platform/app/api/consent`, or any path containing `consent`, `cookie-banner`, `privacy-notice`, or `dpia`
+
+Also loads during full repo scan.
+
+---
+
+## LC-01: ePrivacy cookie consent — strict opt-in, not opt-out
+
+What to grep:
+- `localStorage.setItem`, `sessionStorage.setItem`, `document.cookie =`, `Set-Cookie:`
+- `consent.*=.*true` literals (presumed opt-in)
+- Cookie-banner code that loads SDKs (`<script src=`, `gtag(`, `fbq(`, `posthog.init(`, `mixpanel.init(`) BEFORE a consent decision is captured
+- HTML attributes `checked` on consent inputs
+- Strings: "by using this site you agree", "implied consent", "we use cookies"
+
+Flag when:
+- A non-essential cookie or storage write happens before a consent decision is recorded
+- A consent UI defaults to opt-in (pre-checked box, "Accept" pre-selected, no "Reject" parity button)
+- Third-party scripts load on first paint without a consent-gate guard
+- The "Reject all" path is harder to reach than "Accept all" (cookie-wall pattern)
+
+Why it matters: ePrivacy Directive 2002/58/EC Art. 5(3) and German TTDSG §25 require **prior, freely-given, specific, informed, unambiguous** consent before any non-essential storage or transmission to the user terminal. Implied consent does not satisfy ePrivacy. Pre-checked boxes are explicitly invalid (CJEU C-673/17 *Planet49*).
+
+Fix pattern:
+- Gate every non-essential storage write and SDK load on a recorded consent decision.
+- Default to "Reject all" — the consent banner must surface "Accept" and "Reject" with equal prominence on the same screen layer.
+- Persist consent records (`consent_decisions` table) with timestamp, jurisdiction, banner version, and lawful-basis snapshot.
+
+Regulation: ePrivacy Directive 2002/58/EC Art. 5(3); TTDSG §25; CJEU C-673/17 *Planet49*; EDPB Guidelines 05/2020 on consent.
+
+---
+
+## LC-02: Art. 7 freely-given consent — no bundling, no pre-checks
+
+What to grep:
+- A single consent checkbox covering multiple processing purposes (marketing + analytics + product)
+- `required.*consent`, `consent.*required` patterns where consent is a precondition for service access
+- Pre-checked boxes (`<input type="checkbox" checked`)
+- Consent text that lists multiple recipients or purposes in one bullet
+
+Flag when:
+- One consent action covers more than one processing purpose
+- Consent is required to use the core service (consent is not freely given when refusal blocks access to a service the user paid for)
+- Boxes default to checked
+- Consent for marketing is bundled with consent for terms-of-service acceptance
+
+Why it matters: Art. 7(2) requires consent to be **clearly distinguishable** from other matters; Art. 7(4) requires the freely-given nature to be assessed against bundling. EDPB Guidelines 05/2020 §3.1.2 explicitly bans pre-ticked boxes.
+
+Fix pattern:
+- Split consent into per-purpose toggles, each defaulting to OFF.
+- Decouple service access from consent — the service must remain usable on refusal of non-essential consent.
+- Render terms-of-service acceptance as a separate, non-bundled control.
+
+Regulation: GDPR Art. 7; Recital 32; Recital 43; EDPB Guidelines 05/2020 on consent.
+
+---
+
+## LC-03: Art. 13/14 disclosure — purposes, lawful basis, retention, recipients
+
+What to grep:
+- Privacy-notice copy, cookie-policy copy, account-creation flows
+- Strings: "we may use", "we collect", "we share with"
+- Schema migrations that add a new PII column without a corresponding privacy-notice update in the same diff
+- API endpoints that send user data to a third party without a disclosure entry
+
+Flag when:
+- A new PII column is added but the privacy notice is unchanged in the same diff
+- Disclosure copy lacks any of: processing purposes, lawful basis (Art. 6 / Art. 9), retention period, recipient categories, transfer mechanisms (Chapter V)
+- A new third-party SDK is added without listing the recipient in the privacy notice
+
+Why it matters: Art. 13 (data collected from the data subject) and Art. 14 (data collected from third parties) require disclosure at the moment data is obtained. Missing disclosure is a documentable Art. 13/14 violation regardless of any operational harm.
+
+Fix pattern:
+- Pair every PII-collecting code change with a privacy-notice diff in the same PR.
+- Maintain a recipient register (`compliance-posture.md` Vendor DPAs) and link each disclosure entry to a register row.
+- Render retention periods per data category, not as a single site-wide blanket.
+
+Regulation: GDPR Art. 13; Art. 14; Recitals 60–62; EDPB Guidelines 04/2019 on transparency.
+
+---
+
+## LC-04: Art. 35 DPIA trigger — profiling, Art. 9 at scale, public-space monitoring
+
+What to grep:
+- New automated-decision code paths (`if (score > X) reject`)
+- ML-model inference for credit, hiring, insurance, or eligibility decisions
+- Schema columns named `risk_score`, `eligibility`, `profile_*`, `predicted_*`
+- Art. 9 special-category columns from `fields.md` combined with high-volume / public-facing endpoints
+- Camera, microphone, location-tracking, or biometric capture in public spaces
+
+Flag when:
+- An automated decision produces a legal effect or similarly significant effect on a data subject without a human-review override (Art. 22)
+- Art. 9 data is processed at scale (recital 91: "large scale" assessed by data subjects, volume, duration, geographic coverage)
+- Public-space monitoring is added (CCTV, biometric kiosk, geolocation aggregation)
+
+Why it matters: Art. 35 requires a Data Protection Impact Assessment **before** processing where a high risk is likely. Failing to run a DPIA is itself an Art. 35 violation (and indirectly an Art. 5(2) accountability violation) regardless of whether harm materialises. The CNIL, ICO, and BfDI have all issued fines for missing DPIAs.
+
+Fix pattern:
+- Run an Art. 35(7)-shaped DPIA before the feature ships. Required elements: (i) systematic description of the processing operations and purposes, (ii) assessment of necessity and proportionality, (iii) assessment of risks to data-subject rights and freedoms, (iv) measures envisaged to address the risks. Track the assessment in `compliance-posture.md` Active Items.
+- Consult `soleur:legal:clo` and (for high-risk residual) the supervisory authority under Art. 36.
+
+Regulation: GDPR Art. 35; Art. 36; Recitals 84, 89–96; EDPB Guidelines on DPIA (WP 248 rev.01).
+
+---
+
+## LC-05: Art. 7(3) withdrawal — as easy as giving
+
+What to grep:
+- Account-settings UI, preference center, unsubscribe links
+- API endpoints `POST /consent`, `DELETE /consent`, `PATCH /preferences`
+- Email-template footers
+- Strings: "to unsubscribe, contact support", "to revoke consent, email us"
+
+Flag when:
+- Withdrawal of consent requires more steps, more authentication, or more friction than giving consent did
+- Withdrawal is gated behind a support ticket, email, or phone call when consent was a one-click action
+- The withdrawal control is not present on the same surface where consent was originally given
+- Withdrawal triggers downstream service degradation that wasn't disclosed at consent time
+
+Why it matters: Art. 7(3) requires withdrawal to be **as easy as giving** consent. EDPB Guidelines 05/2020 §5.4 expand this to mean same channel, same number of steps, same UX surface. Asymmetric withdrawal is a documented violation regardless of intent.
+
+Fix pattern:
+- Mirror every consent control with a withdrawal control on the same surface.
+- One-click consent → one-click withdrawal.
+- Persist withdrawal events in `consent_decisions` with the same fidelity as the original consent grant; downstream processing must terminate within a documented SLA.
+
+Regulation: GDPR Art. 7(3); Recital 42; EDPB Guidelines 05/2020 on consent §5.4.

package/skills/gdpr-gate/references/non-negotiables.md

@@ -0,0 +1,60 @@
+# Non-negotiables — GDPR-first, CCPA + HIPAA secondary
+
+Written from scratch for Soleur. The gate's findings sit on these load-bearing articles. Treat each item as a falsifiable claim — if it cannot be answered "yes" against the change under audit, the gate emits a finding.
+
+## GDPR (first-class)
+
+### Art. 5 — Principles relating to processing
+- **5(1)(a) lawfulness, fairness, transparency** — every processing activity has a lawful basis (Art. 6 / Art. 9) declared and reachable.
+- **5(1)(b) purpose limitation** — purposes are specified explicitly; new uses cannot silently piggyback on old consent.
+- **5(1)(c) data minimisation** — collect only what's needed for the declared purpose.
+- **5(1)(d) accuracy** — corrections are propagated; no stale duplicates linger in audit logs.
+- **5(1)(e) storage limitation** — retention is bounded; "forever" is not a retention policy.
+- **5(1)(f) integrity and confidentiality** — encryption at rest + in transit (see data-in-transit layer).
+
+### Art. 6 — Lawful basis (REQUIRED)
+Every column or processing path needs ONE of: consent, contract, legal obligation, vital interests, public task, or legitimate interests. The gate looks for an annotated lawful basis (e.g., comment `-- LAWFUL_BASIS: contract`) on new schema columns. Missing annotation → `Important` finding (`check_id: GDPR-Art-6`).
+
+### Art. 9 — Special categories (LOAD-BEARING)
+Health, genetic, biometric, sex life, sexual orientation, trade-union, religious / philosophical, political, racial / ethnic — see `references/fields.md` Art. 9 list. Column-name match → `Critical` finding (`check_id: GDPR-Art-9`). Critical is reserved for Art. 9 in v1; demoting other findings to Important keeps the Critical signal load-bearing.
+
+### Art. 17 — Right to erasure
+Schema additions linking to a `users` table need a deletion path. `ON DELETE CASCADE` or an explicit anonymisation migration counts; bare FKs without either → `Important` finding (`check_id: GDPR-Art-17`).
+
+### Art. 20 — Portability
+See `layers/data-lifecycle.md` DL-04. Structured machine-readable export reachable for every PII table.
+
+### Art. 25 — Data protection by design
+The gate itself is a Soleur-side embodiment. New features touching regulated data must show evidence of the design-time decisions (DPIA when applicable, see Art. 35).
+
+### Art. 30 — Records of processing activities (RoPA)
+Every controller/processor with regular processing of regulated data maintains a RoPA. Schema additions that introduce a new processing purpose surface a RoPA-update reminder (advisory note, not a gated finding in v1).
+
+### Art. 32 — Security of processing
+Encryption, pseudonymisation, integrity, restoration. See `data-in-transit.md` and `api-layer.md`. Boundary with `soleur:engineering:review:security-sentinel`: OWASP/CWE patterns route to `soleur:engineering:review:security-sentinel`; column-level encryption-at-rest gaps route here.
+
+### Art. 33 — Breach notification (72 hours)
+Plan-time advisory only — the gate cannot enforce an incident-response runbook. Surfaces as a one-line note when `incident`, `breach`, or `notification` keywords appear in plan prose without a corresponding 72h handler.
+
+### Art. 35 — DPIA threshold
+High-risk processing (large-scale special-category, systematic monitoring, automated decision-making with significant effects) triggers a DPIA. The gate flags new schemas matching these patterns with a DPIA-required note.
+
+### Chapter V — Cross-border transfers
+See `layers/data-in-transit.md` DT-EU-CB. Each new non-EEA vendor demands a Vendor DPA row in `compliance-posture.md`.
+
+## CCPA / CPRA (secondary)
+
+- **§1798.100–.130** access + deletion + portability (mostly covered by GDPR Art. 15/17/20 audits).
+- **§1798.135** opt-out signal — if the codebase processes browser hits, the gate notes Global Privacy Control handling absence as a `Suggestion`.
+- **§1798.150** private right of action for data breaches — overlaps with Art. 32; no separate finding in v1.
+
+## HIPAA (secondary)
+
+- **45 CFR §164.502 minimum necessary** — overlaps with GDPR data minimisation.
+- **45 CFR §164.312 technical safeguards** — encryption, audit controls, integrity. See data-in-transit, api-layer.
+- **45 CFR §164.520 notice of privacy practices** — enforced at content layer (see `legal-audit` skill), not at this gate.
+
+## What this gate is NOT
+- Not a legal review. The disclaimer at top of every gate output says so.
+- Not a runtime enforcement layer. v1 fires advisory output; v2 may add preflight gates.
+- Not a substitute for a DPO. Critical findings prompt operator acknowledgment + GitHub issue creation; the issue is the human-routing channel.