67. Communities, Cases and Multiuser Work

The Starter Kit forced the object model to become operational.

The old word problem was too narrow.

AIFC work may be a change, maintenance loop, support request, learning effort, governance review, incident response, or exploration.

So the scoped unit of work became a case.

Cases live under communities.

Personal space can aggregate work across communities, but it does not own shared community truth.

If more than one person belongs to a community, each person should not have to rebuild community metadata separately.

Community metadata belongs to the community.

Local workspaces may cache, edit, view, or propose changes.

They should not silently fork shared purpose, values, decisions, roles, privacy, AI boundaries, skills, and cases into incompatible private copies.

The case model therefore needed state and assignment.

A community needs to know:

• what cases exist,
• what state each case is in,
• who owns it,
• who is currently working on it,
• who reviews it,
• who decides,
• and what the next safe action is.

The first model did not require hard locks.

It used a softer local pattern:

case.md holds stable identity and accountability.

activity.md holds current worker, active session, last activity, next action owner, and soft claim state.

handoff.md tells the next human or AI what to do.

cases/index.md gives the community a registry.

cases/board.md gives the community a working view.

This kept the first kit simple enough for Markdown, but shaped enough for future cloud synchronization, presence, permissions, and cockpit aggregation.