revert: agent/user profile Creatives (Subsystem A) and creator-admin share#1438
Conversation
…1437)" This reverts commit 969da43276b7f6d0e0d63c53e0dbe6b4a45f8fef.
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 810f247036
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # save that omits it makes the row undiscoverable and a duplicate is created. | ||
| # --------------------------------------------------------------------------- | ||
| BUILTIN_RESERVED_METADATA_KEYS = %w[markdown_source content_type editor kind].freeze | ||
| BUILTIN_RESERVED_METADATA_KEYS = %w[markdown_source content_type editor].freeze |
There was a problem hiding this comment.
When an inbox Creative is updated through update_metadata with a payload that omits kind (for example a stale/API payload, or a user removing it from the metadata editor), this list no longer preserves the existing data["kind"]. The save then makes the row stop matching Creative.inboxes/inbox?, so later Creative.inbox_for(user) won't find the existing inbox and will create a duplicate, breaking inbox-specific notification/topic behavior for that user.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Verified — the mechanism is real, and fixed in 18e05b5e. One correction on framing: this is a pre-existing bug, not a regression this revert introduces.
data["kind"] == "inbox" and the Creative.inboxes scope both predate #1412, and kind was not in BUILTIN_RESERVED_METADATA_KEYS before it (25184c9f^ line 12: %w[markdown_source content_type editor]). #1412 added kind there as an independent fix that happened to ride along with the profile-creative work. So the revert restores the pre-#1412 state faithfully — including this bug.
But the chain you describe is real and live on main today: update_metadata replaces data wholesale and only carries over reserved keys, so a payload omitting kind drops the row out of Creative.inboxes → inbox_for no longer finds it → duplicate inbox → that user's inbox notifications and Main-topic behavior split across two rows.
Since the reservation is orthogonal to the design being rolled back, I kept it rather than re-introducing the bug: once the profile/skill discriminators are reverted, kind only ever takes the value "inbox", so reserving it is exactly the inbox-preserving semantic and carries none of the reverted design. This is a deliberate one-word deviation from a pure revert, called out in the commit message.
Regression test (update_metadata preserves the inbox kind so the inbox stays discoverable): creates the user's inbox, PATCHes metadata with a payload omitting kind, asserts the row still matches inbox?, that unrelated keys still save, and that inbox_for returns the same id with no new inbox row. RED without the reservation (inbox creative lost data["kind"] on a metadata save), GREEN with it. Engine models + controllers: 831 runs, 0 failures; rubocop clean.
The revert of #1412 also removed "kind" from BUILTIN_RESERVED_METADATA_KEYS, but that entry was an independent fix for a pre-existing inbox bug, not part of the profile-creative design being rolled back. `update_metadata` replaces `data` wholesale and only carries over reserved keys. `kind` is the discriminator `inbox?` and `Creative.inboxes` match on, so a payload that omits it (a stale metadata popup, or an API client) drops the row out of `Creative.inboxes`; `inbox_for` then no longer finds the existing inbox and creates a duplicate, splitting that user's inbox notifications and topics. `kind` only takes the value "inbox" once the profile/skill discriminators are reverted, so reserving it is exactly the inbox-preserving semantic and carries none of the reverted design. Regression test: a metadata save omitting "kind" leaves the inbox discoverable and `inbox_for` returns the same row.
Reverts both merged PRs of the agent/user profile Creative feature so the design can be reworked from scratch.
feat: grant an agent's creator admin on its profile creative(969da43)feat: agent/user profile Creatives + system prompt sourced from profile (Subsystem A)(25184c9)Both reverts applied cleanly with no conflicts, newest first.
What this removes
HasProfileCreativeconcern and theafter_create_commithook that created a profile Creative per userCreative.profile_for/profile_creative_if_present, thekinddiscriminator and its promoted columnUser#effective_system_prompt— every reader (AI agent service, message builder, orchestration arbiter and context builder, typo corrector, agent type classifier, completions API, admin view, AI settings form) goes back to thesystem_promptcolumnCreativeSharegrant and its backfill migrationVerification
max(version) = 20260724000000,creativeshas nokindcolumn and no profile unique index — matches the reverteddb/schema.rbengines/collavre/test/models370 runs,test/services+test/controllers1215 runs,engines/collavre_completion_api/test12 runs — 0 failuresNote for existing databases
The revert deletes the migration files but does not undo migrations that already ran. Prod is unaffected —
deploy.ymlis manual-trigger only and has not run since 2026-07-15, so these migrations never shipped. Local development databases that already migrated will keep thekindcolumn plusNO FILErows inschema_migrations; recreate them (db:drop db:create db:migrate db:seed) to avoid schema drift.