1  # User Profiles (Radicle-Native)
  2  
  3  These profiles define the **actors** used in this repo’s BDD scenarios.
  4  
  5  The BDD harness and `radicle-priorities` tooling expect each Scenario to include an actor line:
  6  
  7      As a <Profile>
  8  
  9  Where `<Profile>` matches one of the `## Profile:` headings below.
 10  
 11  The intent is not to “model org charts”. These are roles that naturally appear when you
 12  build and operate software in a **peer-to-peer source-control environment** with:
 13  
 14  - cryptographic identities,
 15  - replicated objects by hash,
 16  - patch-based review,
 17  - optional always-on seeds,
 18  - and minimal reliance on centralized services.
 19  
 20  ---
 21  
 22  ## Profile: Backlog Gardener
 23  
 24  **Who this is:** keeps the spec/backlog legible, minimal, and honest.
 25  
 26  **What they want:** contracts that can be implemented without private context.
 27  
 28  **What they do:**
 29  
 30  - Write and edit scenarios in `bdd/features/*.feature`.
 31  - Ensure every `@pending` scenario has exactly one priority (`@p1`/`@p2`/`@p3`) or is consciously left as triage (no priority tags).
 32  - Keep grouping sane via `bdd/FEATURE_CATALOG.md`.
 33  - Curate epic docs and components via `docs/EPIC_CATALOG.md`.
 34  
 35  **What success looks like:** someone can pick a card and ship without guessing what “done” means.
 36  
 37  ## Profile: Steward
 38  
 39  **Who this is:** the person (or small group) responsible for the project’s identity and merge policy.
 40  
 41  **What they want:** collaboration that scales without turning into a single point of control.
 42  
 43  **What they do:**
 44  
 45  - Maintain delegate/merge policy (who can approve patches, what counts as consensus).
 46  - Decide what gets published and what stays private.
 47  - Keep the “official” history coherent while allowing many contributors to work in parallel.
 48  
 49  **What success looks like:** contributors can participate safely, and the project keeps a clear trajectory.
 50  
 51  ## Profile: Contributor
 52  
 53  **Who this is:** builds changes and submits them for review.
 54  
 55  **What they want:** a workflow that works even when they are offline, traveling, or behind hostile networks.
 56  
 57  **What they do:**
 58  
 59  - Clone/mirror the repo locally, make commits, and propose patches for review.
 60  - Attach evidence (tests, repro steps, traces) to make review cheap.
 61  - Suggest improvements to scenarios when reality differs from the contract.
 62  
 63  **What success looks like:** patches move from idea → review → merged with minimal coordination overhead.
 64  
 65  ## Profile: Builder
 66  
 67  **Who this is:** implements features and turns scenarios into working behavior.
 68  
 69  **What they want:** constraints and acceptance criteria that can be verified.
 70  
 71  **What they do:**
 72  
 73  - Pick a scenario (typically `@p1`) and implement until it is no longer `@pending`.
 74  - Keep “works on my machine” honest by producing artifacts others can reproduce.
 75  - Prefer changes that degrade gracefully when peers are offline.
 76  
 77  **What success looks like:** scenarios move from pending → completed and stay completed.
 78  
 79  ## Profile: Reviewer
 80  
 81  **Who this is:** performs patch review (may be a Steward, but doesn’t have to be).
 82  
 83  **What they want:** high-signal diffs, clear intent, and low-risk merges.
 84  
 85  **What they do:**
 86  
 87  - Review patches, request clarifications, and propose edits.
 88  - Check that the change matches the scenario contract (or update the contract if needed).
 89  - Validate that the change doesn’t introduce “central dependency creep”.
 90  
 91  **What success looks like:** review improves quality without becoming a bottleneck.
 92  
 93  ## Profile: Seed Operator
 94  
 95  **Who this is:** runs always-on infrastructure that helps the network converge (without becoming “the server”).
 96  
 97  **What they want:** reliable replication and good uptime without taking custody of everything.
 98  
 99  **What they do:**
100  
101  - Operate a seed node (availability, disk, backups, alerts).
102  - Keep access boundaries explicit (what is public vs private, and who can mirror what).
103  - Provide a stable rendezvous point so new peers can find objects.
104  
105  **What success looks like:** collaboration is smooth for peers in different timezones and network conditions.
106  
107  ## Profile: Release Publisher
108  
109  **Who this is:** makes “what to run” explicit and verifiable.
110  
111  **What they want:** deployability without trusting an opaque build pipeline.
112  
113  **What they do:**
114  
115  - Produce release artifacts and publish a machine-verifiable manifest (hashes + provenance).
116  - Declare upgrade steps and backward-compat constraints.
117  - Keep rollback paths simple.
118  
119  **What success looks like:** operators can run the app and verify they are running the intended bytes.
120  
121  ## Profile: Mirror Operator
122  
123  **Who this is:** runs content-addressed distribution infrastructure for artifacts (bytes by hash).
124  
125  **What they want:** redundancy and availability without central “artifact custody”.
126  
127  **What they do:**
128  
129  - Serve artifacts by digest and retain them for long-lived verification.
130  - Publish where a given hash can be fetched from (so others can mirror).
131  - Keep storage costs predictable via GC policies and retention rules.
132  
133  **What success looks like:** releases remain retrievable even when any one host disappears.
134  
135  ## Profile: Issue Mirror Operator
136  
137  **Who this is:** runs the “metadata mirror” from canonical `.feature` backlog → collaboration surface.
138  
139  **What they want:** issues to be useful for coordination without becoming the source of truth.
140  
141  **What they do:**
142  
143  - Sync pending scenarios into Radicle issues:
144    - `python3 scripts/sync_bdd_issues.py --apply`
145  - Keep labels aligned with priority + categories + kanban state.
146  
147  **What success looks like:** `rad issue list` reads like a prioritized backlog, but edits still happen in `.feature` files.
148  
149  ## Profile: Suite Operator
150  
151  **Who this is:** runs this test suite against other repos to decide “does it qualify?”.
152  
153  **What they want:** a repeatable, explainable pass/fail report.
154  
155  **What they do:**
156  
157  - Run `scripts/radicle_native_probe.py` against a target repo.
158  - Publish the resulting report (and the reasoning behind failures).
159  - Propose minimal patches that move a repo from “nearly compatible” to “compatible”.
160  
161  **What success looks like:** teams can converge on shared standards without gatekeeping or ambiguity.
162  
163  ## Profile: Auditor
164  
165  **Who this is:** validates that a project’s claims match reality (security, governance, reproducibility).
166  
167  **What they want:** verifiable artifacts and inspectable workflows.
168  
169  **What they do:**
170  
171  - Check that identities, policies, and release evidence are consistent.
172  - Look for “hidden dependencies” on centralized accounts/services.
173  - Demand crisp invariants: what must be true even under partial network failure.
174  
175  **What success looks like:** the system is trustworthy without relying on reputation alone.