Spike: Facebook Page reached after the operator's Page click; scheduled post + photo created, read back byte-equal, deleted
gates / gates (push) Successful in 4m35s
gates / gates (push) Successful in 4m35s
Read phase passes (Page 1360018983863273, CREATE_CONTENT/MODERATE/ANALYZE, page token PAGE expires_at 0, three insights metrics alive on v26.0). Write test: removal check accepts Meta's code-10 'Object does not exist' (fixed without a row, 4 tests); run 1 evidence kept. R-914 READY, R-915 narrowed to Live mode.
This commit is contained in:
@@ -274,8 +274,8 @@ stopping line that lies.
|
||||
| **R-901** | Business & legal | P2 | **Two kinds of a household's data outlive the deletion of the customer, and no document says when they go.** FOUND 2026-10-08 (R-813 drafting), read in source: the hub keeps `events` and `notification_log` on purpose after a customer is deleted (`hub/internal/store/customer_delete.go:24-26`, „the audit trail outlives every lifecycle tier") and nothing prunes `notification_log`; DooPlex's copy of ep0 (`ep0-copy`) pulls with `remove-vanished false` and prunes only to keep-weekly 8 (`runbooks/ep0-datastore-copy.md`), so a deleted customer's last 8 weekly encrypted whole-guest copies stay on DooPlex with no end date. A privacy notice cannot promise deletion until this is decided. **-- 2026-10-08 14:16 operator ruling D9 (`09` §3 decision 193):** yes — CC installs the DooPlex job, dry run first, then daily, after the 2026-10-09 releases are read back. | **READY — ruled 2026-10-08 09:04 (`09` §3 decision 181): audit rows (`events`, `notification_log`) of a deleted customer kept 1 year, then deleted; the customer's `ep0-copy` namespace removed within 30 days; both go into the privacy-notice draft.** Close only when both are live. | R-813 | Build the hub's daily deletion (ships with the next hub release) and the DooPlex `ep0-copy` removal job (written; run needs the operator's word); write both times into the privacy-notice draft | CC |
|
||||
| **R-89** | Business & legal | P4 | Retention as a per-customer **commercial** policy on the hub | READY (increment 2) | — | Policy object + reconciler → ep0 prune job; keep box tokens write-only | CC |
|
||||
| **R-794** | Business & legal | P4 | **[P3-LOW] redis 7.4 (RSALv2 / SSPL, not OSI) runs as a private cache in seven apps: dawarich, docmost, immich, nextcloud, outline, paperless-ngx, romm.** READ 2026-10-02 (`audits/licences-2026-10-02/TABLE.md`). Read as permitted (a private cache only its app uses is not Redis offered as a service — inferred). Valkey (BSD-3) or redis 8 (AGPL option) removes the question. **Needs:** a ladder step per app to valkey or redis 8, through the harness — no hurry. | **READY — rank P3-LOW; owner: CC** **Re-ranked 2026-10-03: P3→P4: the row itself says no hurry; usage read as permitted.** | — | — | CC |
|
||||
| **R-914** | Business & legal | P4 | **Write the Felhom Facebook Page skill from the spike's findings.** Spike 2026-10-08 (`audits/SPIKE-facebook-page-api-2026-10-08.md`): the system-user key is valid and never expires, but reaches no Page, so the post/photo/read paths are unmeasured. Probe `scripts/facebook/fb_probe.py`. | **BLOCKED** — on R-915 (the Page is not assigned to the robot) | R-915 | After R-915: re-run `fb_probe.py -v read`, then `write-test` (scheduled post + photo, read back, deleted); finish the spike table; then write the skill (drafts scheduled for operator review by default) | CC |
|
||||
| **R-915** | Business & legal | P4 | **The Facebook robot (`felhom-cc`) has no Page, and the Meta app is in development mode.** MEASURED 2026-10-08: `/me/accounts` returns `{"data": []}` (`audits/facebook-page-api-2026-10-08/B2-me-accounts.json`). READ (Meta docs, cited in the spike): posts made in development mode are seen only by people with a role on the app; Live needs display name, contact e-mail, a Terms of Service URL, an app icon, a category and the app purpose (privacy-policy and data-deletion URLs listed beside them). | **WAITING-ON-OPERATOR** | — | (1) Meta Business Suite → Settings → Users → System users → felhom-cc → Assign assets → Pages → Felhom.eu → Full control (if the Page is not listed: Settings → Accounts → Pages → Add it first). (2) Before real posts: switch the app to Live — needs the Terms of Service URL (R-813). If nothing is done: CC cannot post; nothing breaks | operator |
|
||||
| **R-914** | Business & legal | P4 | **Write the Felhom Facebook Page skill from the spike's findings.** Spike 2026-10-08 (`audits/SPIKE-facebook-page-api-2026-10-08.md`): key valid, never expires; the Page (`1360018983863273`) is reached with CREATE_CONTENT/MODERATE/ANALYZE; a scheduled text post and a scheduled photo were created, read back byte-equal and deleted (removal proven). Probe `scripts/facebook/fb_probe.py`. Gap to close in the skill: a scheduled photo's publish state was not read (no `post_id` returned). | **READY — owner: CC** | — | Write the skill (drafts scheduled for operator review by default); read a scheduled photo back through the Page's scheduled-post listing | CC |
|
||||
| **R-915** | Business & legal | P4 | **The Meta app `felhom.eu` is in development mode, so posts it makes are seen only by people with a role on the app.** READ 2026-10-08 (Meta docs, cited in the spike); not measured. MEASURED: development mode does not refuse posting (both test writes HTTP 200). Live needs display name, contact e-mail, a Terms of Service URL, an app icon, a category and the app purpose (privacy-policy and data-deletion URLs listed beside them). The robot's Page assignment, missing at first, was done by the operator the same day. | **WAITING-ON-OPERATOR** | R-813 (the Terms of Service URL) | Before real public posts: switch the app to Live in the Meta developer page. If nothing is done: posts stay invisible to the public | operator |
|
||||
|
||||
## Process & tooling — 23 rows (P3 3, P4 20)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user