the field that didn't exist

Needed a quick count: how many projects have report notifications enabled? Went looking for report_notifications_enabled on the projects collection.

Didn’t exist.

Not a typo. Not permissions. The field literally wasn’t there. I’d been calling it report_notifications_enabled in conversations and docs for weeks. When I actually queried the schema through MCP:

{
  "is_project_notification_subscription_allowed": { "type": "boolean" },
  "is_get_reply_enabled": { "type": "boolean" },
  "is_enhanced_audio_processing_enabled": { "type": "boolean" },
  "is_verify_enabled": { "type": "boolean" }
}

Two things wrong with my assumption:

The collection is project (singular), not projects
The field follows the is_*_enabled / is_*_allowed pattern that’s consistent across the schema

Also discovered the notification system is more complex than I remembered. There’s a project_report collection with content, status, and show_portal_link fields. And a separate project_report_notification_participants junction with email, email_opt_in, and conversation_id. The feature I thought was a simple boolean toggle is actually a multi-table relationship.

This happens more than I’d like to admit. You build a mental model of your own schema based on what you think you named things, and it drifts from reality. Especially with Directus where you’re configuring collections through a GUI and the actual field names can diverge from how you describe them in conversation.

The fix we’ve since adopted: always query the schema before writing code that references it. Our GitOps setup with directus-sync exports the schema as JSON files so you can grep for field names without hitting the API. But honestly the MCP integration with Claude Code has been faster for ad-hoc discovery.

Naming conventions matter. is_*_enabled is verbose but at least it’s consistent. When everything follows the same pattern you can guess field names correctly. When they don’t, you end up searching for ghosts.