Skip to content

Remove Neon-only identity resolver: Motion-web identity resolves from the local daemon DB #134

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Kyra Richards (kyra-cpu) merged 2 commits into from
Jun 12, 2026
Merged

Remove Neon-only identity resolver: Motion-web identity resolves from the local daemon DB #134

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
86398b4
Swap Neon-only identity resolver for local daemon-DB resolver
Jun 12, 2026
865b2fd
Drop incident narrative from changelogs
Jun 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions add-roles-permissions/CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,32 @@ All notable changes to `deploy-security-protocol` are documented here.

---

## v3.3.0 — 2026-06-12

Remove the Neon dependency from Motion-web identity resolution. Installs no longer require — or ask for — any production database credential.

### Why

The June 2026 runtime change added a local daemon conversation store (`/daemon/conversation-store/conversations.db` plus a `$CONVERSATION_ID` env var), which makes Motion-web identity resolvable locally. The fleet's resolvers were updated to use it in the June 10–11 rollout, but this repo's install path was never updated to match — it still asked for a runtime database secret at install time. A fresh install should never prompt for a database credential. This release brings the repo in line with the fleet.

Version is 3.3.0 (not 3.2.x) because PR #115 has v3.2.0 claimed for the attribution-layer removal.

### Changed

- **`motion-whoami.sh` resolves locally.** Reads `userEmail` from `/daemon/conversation-store/conversations.db` (via `sqlite3 -readonly -json`) using the runtime-injected `$CONVERSATION_ID`, then resolves against `organization-map.json`. No network, no secrets. The script body matches the resolver proven on ~10 customer VMs in the June 2026 fleet rollout (compatibility variant, SHA `946bfa2a043944075ba0ad415faa35a28d668cca07131fbeea551244e5f85d01`), adapted only to this package's naming: `organization-map.json` / `RUNNETH_ORG_MAP` and `/agent/brain/team/` home bases (the fleet uses `workspace-map.json` / `/agent/brain/members/`).
- **Fail-loud semantics kept** (decided 6/2): on resolver failure — `$CONVERSATION_ID` unset, daemon DB missing, no email for the conversation — the script exits non-zero with error JSON on stderr, and the permissions layer treats unknown identity as no-writes.
- **Legacy-map compatibility:** the resolver reads `.motionUserEmails` and falls back to legacy `.motionEmails`, and keeps both in sync on provision, so older installs keep resolving existing users after upgrade.
- **Phase 1 Look-around 6** no longer checks for a runtime secret and no longer hard-stops fresh installs. It now checks the two things the resolver needs — daemon DB present, `sqlite3` available — both on every current VM by default. If either is missing (outdated image), warn and proceed; Motion-web users resolve as unknown until the runtime is updated.
- **Prerequisites** (SKILL.md + README): `NEON_DATABASE_URL` dropped; `sqlite3` added.

### Removed

- **`motion-whoami-neon.py`** and its install step. Phase 5 Step 4 now tells the agent to delete a leftover copy if one exists from a prior install.

Refs: PDEC-7817.

---

## v3.1.5 — 2026-06-03

Slim pass. 73 lines trimmed from SKILL.md (1,137 → 1,064) without dropping a single rule, look-around, phase, or piece of educational content. Pure deduplication and prose tightening.
Expand Down
15 changes: 7 additions & 8 deletions add-roles-permissions/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ The skill is built from six primitives. The install conversation discovers which
3. **Writers per space.** Each space has a writer rule: `everyone`, `specific`, or `admins_only`. Default is `everyone`. Anything in `everyone` is implicit and does not need to be listed.
4. **Attribution.** Every durable save under `/agent/brain/` carries `author: @<handle>`. Always on.
5. **Approval routing.** Optional Slack channel where blocked-edit requests get posted with the requester's handle, the space they tried to edit, and a short summary. Admins approve or decline in a follow-up message.
6. **Identity resolution.** Slack ID or Motion email → handle. Neon-only (queries `agent_conversation`). No SQLite fallback.
6. **Identity resolution.** Slack ID or Motion email → handle. Motion-web identity reads the local daemon conversation store (`/daemon/conversation-store/conversations.db` via `$CONVERSATION_ID`). No runtime secrets required. Fails loudly: unknown identity means no writes.

The install flow shapes these into the org's setup.

Expand All @@ -34,8 +34,7 @@ The install flow shapes these into the org's setup.
│ ├── spaces.json ← protected areas + writer rules + approval channel
│ ├── organization-map.json ← people registry
│ ├── slack-whoami.sh ← Slack resolver + auto-provisioning
│ ├── motion-whoami.sh ← Motion web resolver (Neon-only) + auto-provisioning
│ └── motion-whoami-neon.py ← Neon agent_conversation query helper
│ └── motion-whoami.sh ← Motion web resolver (local daemon DB) + auto-provisioning
├── members/ ← per-person home bases (owner-write only)
│ └── <handle>/{<handle>.md, brain/, conversations/}
└── (any protected spaces the conversation produced — paths chosen with the admin)
Expand All @@ -49,7 +48,7 @@ The install flow shapes these into the org's setup.

Seven phases. The admin sees a conversation; the agent runs the rest behind the scenes.

1. **Look around and plan.** The agent silently inspects the VM: existing `permissions.md`, prior-version files, suspicious content in `user.md`, partial installs, Neon-secret availability. Holds the findings in memory.
1. **Look around and plan.** The agent silently inspects the VM: existing `permissions.md`, prior-version files, suspicious content in `user.md`, partial installs, daemon conversation-store availability. Holds the findings in memory.
2. **Framing the opening.** Composes the opening turn in its own voice, shaped by the admin's triggering message and what Phase 1 surfaced. No canned script.
3. **The conversation.** Flowing chat. The agent listens for: who's on the team, the work shape, content categories that come up, **areas where only certain people should be editing**, areas that should stay open, and who the first admin is (plus a backup). If protected areas come up, the agent also asks about an approval channel and a backup approver. Brain-organization questions (where to put notes, how to group playbooks) get punted: "I can think about that separately — it's not part of this setup."
4. **Read it back, then confirm.** Plain-language summary in the admin's words, with writers named per space so wrong attribution is easy to spot. Confirms before any writes.
Expand Down Expand Up @@ -81,8 +80,8 @@ The conversational tone, the communication style (no code or JSON in chat unless
- Admin running the skill (or the instance owner on a fresh sandbox).
- `/agent/` writable.
- `/agent/user.md` exists (may be blank).
- `jq` installed.
- `NEON_DATABASE_URL` runtime secret configured. Hard-stop on fresh installs without it: Motion-web users would resolve as unknown on every message and writes would be blocked. Existing installs get a soft warn so reconfigures can proceed offline.
- `jq` and `sqlite3` installed.
- `/daemon/conversation-store/conversations.db` present (the runtime maintains it on every current VM by default). Motion-web identity resolves locally from it — no runtime secrets required. If it's missing the image is outdated: Motion-web users resolve as unknown (no writes) until the runtime is updated.

---

Expand All @@ -93,7 +92,7 @@ Safe to re-run. Specifically:
- `organization-map.json` merges; identity entries are never deleted.
- `spaces.json` archives the prior version to `/agent/brain/admin/.archive/` before any reconfigure write, then merges. Spaces not mentioned in a new conversation are preserved as-is; never silently deleted.
- `permissions.md` is regenerated from `spaces.json`. The old one is archived before overwrite.
- `slack-whoami.sh` / `motion-whoami.sh` / `motion-whoami-neon.py` are pure scripts and safe to rewrite.
- `slack-whoami.sh` / `motion-whoami.sh` are pure scripts and safe to rewrite.
- `user.md` only prepends the protocol pointer if absent; updates in place if the installed version differs (with explicit admin confirmation).
- Member home bases are never deleted by reconfigure.

Expand All @@ -111,7 +110,7 @@ Safe to re-run. Specifically:

## Source

- **Skill version:** 3.0.0
- **Skill version:** 3.3.0
- **Source org:** Motion (Creative Analytics)
- **Predecessor:** `deploy-admin-permissions@2.3.0`
- **Refs:** PDEC-7817
Loading
Loading