docs: transition repository to role-engine

INTENT.md

@@ -0,0 +1,116 @@
+# INTENT
+
+> Status: Draft
+
+## Purpose
+
+`role-engine` exists to define reusable organizational and operational roles in
+one coherent, versioned repository.
+
+The repository replaces the tentative one-repository-per-role model. A role is
+a governed definition within this repository, not a repository boundary of its
+own. This keeps shared concepts consistent, makes roles easier to compare and
+maintain, and avoids multiplying repositories for closely related documents.
+
+The first definition is the
+[Community Manager — Coulomb Society](roles/community-manager.md) role.
+
+## Primary utility
+
+`role-engine` should give people, teams, and automation agents a clear contract
+for what a role is expected to accomplish and where its authority stops.
+
+Role definitions may describe:
+
+- purpose and intended outcomes;
+- responsibilities and recurring activities;
+- required competencies and expected behavior;
+- decision rights and escalation requirements;
+- interfaces with people, teams, systems, and other roles;
+- success criteria and evidence of effective operation.
+
+The definitions should be useful for role design, recruitment, onboarding,
+delegation, agent prompting, operating reviews, and organizational change
+without being coupled to one execution platform.
+
+## Core principles
+
+### One model, many roles
+
+Roles share a repository and, as the catalog matures, a common vocabulary and
+structure. A genuinely independent product or service may still warrant its own
+repository; a role definition alone does not.
+
+### Roles are not identities
+
+A role describes expected authority and behavior. It does not identify the
+person, team, or agent currently filling it. Assignments and identity records
+belong in the systems that govern people, agents, and access.
+
+### Roles are not permissions
+
+Decision rights in a role definition express organizational intent. They do not
+grant technical authorization. Access remains subject to the relevant identity,
+policy, and authorization systems.
+
+### Definitions before machinery
+
+The repository begins as a documentation-first catalog. Schemas, validation,
+rendering, APIs, or automation should be introduced only when real consumers
+make their requirements clear.
+
+### Context remains explicit
+
+Some roles are reusable across organizations; others are specific to a domain,
+community, or operating environment. Definitions should state that context
+rather than pretending every role is universal.
+
+## Initial scope
+
+The initial repository should own:
+
+- the role catalog under `roles/`;
+- guidance for writing and reviewing role definitions;
+- shared terminology and structure once repeated patterns are demonstrated;
+- version history for substantive changes to role purpose, authority, or
+  responsibilities;
+- links between related roles where coordination or escalation depends on them.
+
+## Out of scope
+
+`role-engine` should not initially own:
+
+- personnel records, hiring decisions, or employment contracts;
+- live assignment of people or agents to roles;
+- authentication, authorization, credentials, or permission enforcement;
+- task management, scheduling, or workflow execution;
+- performance surveillance or individual activity tracking;
+- a runtime service merely to justify the word `engine`;
+- separate repositories for each role.
+
+## Evolution direction
+
+The next useful step is to learn from the Community Manager definition and any
+second role before standardizing a schema. If multiple consumers later need
+machine-readable definitions, the repository may add stable identifiers,
+structured metadata, validation, rendered views, and compatibility rules while
+keeping the human-readable role contract authoritative.
+
+## Success criteria
+
+The direction is working when:
+
+- adding a role is normally a focused file change, not repository creation;
+- related roles use consistent language for responsibility, authority,
+  interfaces, escalation, and success;
+- a reader can distinguish a role definition from an assignment or permission;
+- role changes have clear reviewable history;
+- people and agents can reuse the definitions without depending on a particular
+  workflow or identity system;
+- additional machinery is added in response to demonstrated needs rather than
+  speculation.
+
+## Guiding statement
+
+`role-engine` maintains clear, reusable role contracts while leaving identity,
+assignment, authorization, and execution to the systems that own them.