[Data Contract] Migrate every database object to descriptive multiword names

[seonghobae]

Buyer and operator problem

The current SQLite schema contains ambiguous one-word object names such as users, orgs, projects, tasks, invites, webhooks, baselines, comments, sprints, and attachments. They conflict with the organization rule that every database object name must contain at least two lexical words, with descriptive snake_case preferred. They also make cross-service extraction, analytics contracts, migration review, and incident diagnosis unnecessarily ambiguous.

This is a dedicated migration train, not an opportunistic rename inside the active attachment/authentication security pull requests.

Required target contract

Create a complete, reviewed inventory of tables, views, indexes, triggers, constraints, migration-ledger objects, and columns. Every final persisted object must use at least two meaningful words and one consistent snake_case convention. Illustrative table mappings are:

• users → user_accounts
• orgs → organization_accounts
• memberships → organization_memberships
• projects → project_records
• tasks → project_tasks
• invites → project_invitations
• webhooks → webhook_endpoints
• baselines → project_baselines
• comments → project_comments
• sprints → project_sprints
• attachments → project_attachments

The final mapping must be generated from the real schema and SQL call sites rather than accepting these examples blindly. Generic columns such as id, name, status, or type must also be evaluated and renamed where they are database-schema objects rather than API-local aliases.

Architecture and MSA requirements

• Keep standalone ScopeWeave fully operable throughout the migration.
• Separate the physical schema mapping from domain repositories so future services can import one module without copying SQL literals.
• Do not expose physical table names through public REST, event, export, or metrics contracts.
• Use explicit repository or data-access ports for authentication, projects, work items, attachments, audit history, and integrations.
• Keep SQLite as the supported standalone implementation while documenting a portable PostgreSQL mapping for service extraction.
• Do not retain one-word compatibility views or aliases in the final schema. A bounded transitional compatibility phase is allowed only inside the migration and must be removed before completion.

Migration safety

• Build an idempotent, transactional migration from a realistically populated legacy database.
• Preserve every row, foreign-key relationship, uniqueness rule, timestamp, token version, audit record, webhook delivery, attachment job reference, and baseline snapshot.
• Detect interrupted or partially applied migrations and fail closed with an actionable operator message.
• Back up or snapshot the database before destructive steps and document restore/rollback.
• Validate foreign keys and row-count/checksum invariants before committing the migration.
• Ensure startup cannot create a mixed old/new schema.
• Define the minimum supported downgrade behavior; never silently start an older binary against the renamed schema.

Test and evidence contract

• TDD: migration tests fail before implementation.
• Use a populated fixture spanning multiple organizations, members, projects, task hierarchies, invitations, comments, sprints, baselines, attachments, API tokens, audit entries, webhooks, and webhook deliveries.
• Prove pre/post row-count and relationship equivalence, authentication continuity, logout-all continuity, project authorization, attachment listing/viewing, webhook retries, exports, and restart idempotence.
• Prove failure rollback for malformed legacy schemas, duplicate target data, interrupted migrations, foreign-key violations, and unavailable backup destinations.
• Prove no final sqlite_master entry or schema column violates the multiword naming rule.
• Require 100% statement, branch, function, and line coverage for migration and repository code, complete beginner-readable docstrings, and exact-head cloud E2E/security checks.

Documentation and release

• Add docs/doctoring/database-object-naming-migration.md with the complete inventory, mapping, data invariants, rollback plan, MSA boundary, and APA 7th references to authoritative SQL/database migration guidance current at implementation time.
• Update operator deployment/backup/restore documentation and CHANGELOG.md.
• Treat the completed migration as a breaking storage-schema change. Bump the release version according to the repository's semantic-versioning policy only after upgrade and rollback evidence is complete.

Delivery order

Implement after the active attachment and session-security train has merged. Do not mix physical-schema churn with #432, #414, or the scoped URL access-grant work in #413.

[seonghobae]

Closed as a duplicate of #433, which is the earlier canonical expand/verify/contract migration ledger and is already referenced by dependent work such as #414. The useful extra acceptance details recorded here—including a complete real-schema inventory, evaluation of column names, and removal of transitional one-word compatibility aliases before completion—remain preserved in this issue and should be carried into #433's implementation review.