Skip to content

Business workflow roadmap: Church and Basketball first #252

Open
Open
Business workflow roadmap: Church and Basketball first#252
Labels
enhancementNew feature or requestphase: platform-laterPlatform, release and native work deferred until business-flow acceptance.

Description

@tomqwu
tomqwu
opened on Sep 9, 2026

Current Roadmap

Owner decisions: The Church/Basketball business-first order was accepted on 2026-09-13. The completed business workflow was accepted on 2026-09-15 in #289.

Current Outcome

The business workflow milestone is complete on merged main. The active track is release/platform readiness. Paid billing/SMS and native store release remain optional, separately authorized work.

Execution Order

  1. P2: Build and validate the production artifact after business acceptance #265 — artifact and staging: preserve the reproducible production image, local TLS/security evidence and rollback commands merged in PR Add loopback TLS artifact rehearsal #338 and the guarded staging runner merged in PR Add guarded staging acceptance runner #339; complete deployment and smoke only after the owner supplies a disposable staging target and explicitly authorizes deployment.
  2. P2: Add production monitoring after business-flow acceptance #267 — monitoring: after a staging target and operator destination exist, trigger one controlled error, correlate it, and prove a real operator receipt without leaking sensitive data.
  3. P2: Prove production recovery and retention after business acceptance #268 — recovery and retention: after the owner approves RPO/RTO, retention, key custody and legal-hold policy, run backup/restore and retention evidence in an isolated environment.
  4. P2: Reconcile platform assurances with later release evidence #284 — assurance reconciliation: keep the documentation/evidence matrix truthful while P2: Build and validate the production artifact after business acceptance #265/P2: Add production monitoring after business-flow acceptance #267/P2: Prove production recovery and retention after business acceptance #268 finish; reconcile the final staging and operations receipts.
  5. P2: Run production release acceptance after business flows are accepted #271 — release acceptance: freeze one candidate and execute the full role journeys, load/recovery/rollback checks and owner pilot go/no-go after the preceding evidence exists.
  6. P2: Regenerate the mobile API client and validate native release #191 / P3: Defer paid billing and SMS product acceptance #270 — optional later tracks: resume native release or paid billing/SMS only when the owner explicitly selects and authorizes that track.

Current Evidence

External Inputs Required

  • A disposable staging platform/project, region and hostname plus explicit deployment authorization.
  • A named operator and real alert destination for the controlled monitoring drill.
  • Owner-approved RPO, RTO, retention, key-custody and legal-hold decisions.
  • Pilot cohort, support owner, data policy and final go/no-go authority.

Guardrails

All tests and code review run locally. GitHub Actions does not run tests, and Ollama is not a code-review provider. Builder agents merge only when GitHub reports the PR mergeable and the exact local evidence is recorded. Do not deploy, activate paid providers, use production data, contact real recipients, sign/store-submit native apps or infer production readiness without the corresponding explicit authorization.

The detailed historical roadmap below remains traceability, not the current queue.

Builder Handoff Contract

Updated 2026-09-13 for execution by a lower-cost model. This plan moves architectural recommendations, test oracles, scope boundaries and escalation rules into the issues. It does not require xhigh for implementation or claim a reasoning setting was changed in this task. No model can guarantee correctness from a detailed ticket alone.

No CI checks. All code review, formatting, lint, type checks, migration checks, unit/API/CLI/integration/web/contract/Playwright/mobile tests, scans and artifact verification run locally. No synthetic success statuses or Ollama reviewer. Pages publication remains separate.

Scope and handoff inventory

The earlier handoff pass covered 30 open issues, with 29 implementation briefs, 116 work packages and 116 regression cases. The business-first update adds #287 response semantics, #288 noncommercial core flows and #289 role-by-role business acceptance, for 33 open issues. Earlier packages remain detailed reference, not permission to execute the deferred tracks.

Each implementation brief contains current source pointers, what is already implemented, recommended decisions, hard versus coordination dependencies, bounded work packages, test oracles, existing local commands, migration/compatibility requirements, stop conditions, focused review questions and a copyable builder prompt. Read the top Current Implementation Handoff before older audit context.

Verified local and remote main baseline: 21a4a804aa57580451edded04736b1f51aef7e48. Recheck current source at execution time; never reset to this baseline or overwrite concurrent work. Source inspection and issue updates are not new test execution.

Important source corrections

These corrections supersede contradictory historical implementation statements below and in old issue evidence. Test existing controls before deciding to replace them.

Execution loop for a smaller builder

  1. Read the selected issue's top brief, source pointers, required dependency receipts and AGENTS/CLAUDE/current testing policy. Do not load the full 1,307-file repository or all issue bodies into one prompt unless the selected slice truly needs it.
  2. Choose one ready work package, not the entire roadmap. State intended files, preserved behavior, test IDs and exact completion condition before editing. Work packages are the unit of implementation; issue closure waits for all packages and acceptance.
  3. Start with a focused failing regression that distinguishes the defect from fixture/environment failure. Implement the smallest change in existing patterns; no unrelated framework rewrite, schema cleanup or dependency churn.
  4. Complete code, local regression tests, negative cases, affected docs/README/playbooks/screenshots and issue evidence together. A package is not done merely because its code compiles or the happy path works.
  5. Run local formatting/lint/touched-module types, unit and full test suites on the final tree. Obtain real browser screenshots for UI work; inspect them. Use explicit PostgreSQL/device/provider/artifact stages where needed and mark unavailable stages blocked.
  6. Request a fresh local reviewer context over the head/base diff and package acceptance. The same lower-cost model may perform a fresh review, but that is not a guarantee of independence or correctness. Security/transactions/migrations/financial changes deserve stronger review when available; do not auto-switch models or incur extra spend without owner approval. A reviewer never merges.
  7. Resolve findings and rerun affected validation. If user scope authorizes PR/merge, record exact head/base SHAs and current results, then confirm GitHub mergeability and required reviews. Do not fabricate checks or bypass protections.
  8. Verify merge/source state if merged, update package/test receipts and dependent readiness, and leave the parent open for unfinished work. No deployment, live provider enablement, customer-data purge or store submission is implied.

Escalate the affected package when business policy is unresolved, prerequisites are unavailable, transaction/ownership semantics are ambiguous, source drift invalidates the plan, or two focused repair attempts yield no new evidence. Post reproduction/commands/expected-versus-actual and the smallest decision needed. Do not suppress tests, reinterpret failures as success or keep expanding the patch.

Local validation protocol

Run in the safely isolated environment established by #281. Before that environment exists, only run narrowly verified fixture/static tests with no shared data or provider side effects.

Existing commands:

poetry run black --check api tests
poetry run ruff check api tests
poetry run mypy --no-incremental api/utils api/core api/schemas
poetry run mypy api
make test-unit
make test-all

Also check maintained web/scripts modules touched by the package using applicable formatter/linter/type commands. Whole-API legacy typing debt must be recorded separately, never hidden; changed scope must pass and add no unaccepted regression. #281 owns expanding/defaulting this checked scope.

Run make test-mobile and native analysis/build/integration for mobile/schema compatibility work as specified in #191. Run API and browser tiers in separate pytest processes. The current make test-all covers seven Python tiers; #281 must repair the missing make test target and classify/add safe omitted cases before anyone claims every test runs. Newly proposed commands such as make test-postgres or a screenshot-capture entry point are not existing commands until their owner issue implements and documents them.

Do not reset shared DBs, call provider endpoints or run the hardcoded legacy load target to obtain evidence. For #260/#265/#267/#268/#270/#271 use explicitly owned/authorized targets. Report source tests, database engine tests, built artifact tests, external delivery, devices and release approval separately.

Before an authorized merge, an existing read-only check is:

gh pr view <PR_NUMBER> --repo tomqwu/SignUpFlow --json headRefOid,baseRefOid,mergeable,mergeStateStatus,reviewDecision

Compare those SHAs with the test/review receipt. mergeable=MERGEABLE alone is insufficient without local evidence and required reviews; unknown/conflicting/blocked state needs resolution, not a force merge.

Earlier Full-Release Dependencies (Not the Current Execution Queue)

This is not a rule to finish a broad documentation issue before starting the backend. Complete its ready packages, keep it open, and revisit its final reconciliation after behavior/artifacts are ready. Coordination links are not hard dependencies. Hard-dependency graph was checked for missing targets and cycles.

Issue Hard prerequisites for dependent implementation/acceptance Risk focus
#281 None for first isolated slice High: trustworthy local validation and test isolation
#283 None for first isolated slice High: process and database safety
#282 None for first isolated slice Medium/high: autonomous task safety and completion discipline
#277 None for first isolated slice Medium: misleading instructions and incomplete documentation coverage
#278 None for first isolated slice Medium: broken onboarding examples and misleading public claims
#284 None for first isolated slice Medium/high: false security and operational assurances
#254 None for first isolated slice High: cross-tenant exposure and export scope
#255 None for first isolated slice High: identity bootstrap and privilege assignment
#256 None for first isolated slice High: financial object authorization
#257 None for first isolated slice High: tenant-scoped messaging and webhook authenticity
#258 None for first isolated slice High: fail-closed production configuration
#260 None for first isolated slice High: database isolation, migrations and concurrency evidence
#253 #260 High: tenant deletion and transactional audit
#261 #258 High: browser CSRF, sessions and distributed abuse limits
#263 #254, #255 High: persisted rule semantics and scheduler correctness
#262 None for first isolated slice High: account recovery and real delivery evidence
#264 #254, #260, #263 High: concurrent allocation and irreversible roster races
#266 #258, #260 High: durable side effects and cross-worker consistency
#286 #254, #260, #263, #264 High: publication transaction, roster completeness and future-shift loss
#285 #281 Medium/high: complete browser workflows and inaccessible controls
#279 #254, #255, #263, #264, #281, #286 High: end-to-end scenario truth and reusable test coverage
#265 #258, #260 High: release artifact and operational rollout
#267 None for first isolated slice Medium/high: truthful probes, logging and alert evidence
#268 #260, #265 High: data loss, recovery and retention
#269 None for first isolated slice Medium/high: dependency and release supply-chain assurance
#280 #279, #281, #285 Medium: visual artifact provenance and actual UI evidence
#271 #253, #254, #255, #256, #257, #258, #260, #261, #262, #263, #264, #265, #266, #267, #268, #269, #279, #280, #281, #284, #285, #286, #277, #278, #282, #283 High: production go/no-go and acceptance evidence
#191 #254, #255, #257, #263 Medium/high: generated client contracts and native release
#270 #256, #257, #258, #266 High: optional paid features and external delivery

Earlier platform-oriented batches, retained for later release planning (superseded for current execution by the Business-First Order above):

File ownership and integration boundaries

Owner decisions and external prerequisites

These are real blockers for affected slices, not questions the smaller model should silently answer:

Decision / prerequisite Recommended starting position Owner issues
Public signup compatibility Atomic org + first-admin bootstrap; existing-org membership via invitation; approve migration before changing public contract #255
Publication policy One active full future horizon, all required slots/hard rules valid, no override in the first implementation; approve manual/open-shift and response-state semantics #286
Domain eligibility Role qualification is not safeguarding/medical/league certification; unsupported team/rest/venue rules remain explicit #263/#279
Production target and proxy/TLS trust Owner names region/provider/public origins/operator/budget; use synthetic local equivalents until approved #258/#261/#265
PostgreSQL/Redis/Docker Explicitly owned local disposable targets; no fallback claimed as PostgreSQL success #260/#265/#266
Retention, audit, encryption and recovery Owner approves holds/purge/key custody and measured RPO/RTO; no real purge from a plan #253/#268
Alerts and support Named authorized sink/on-call owner, measured thresholds and recovery behavior #267/#271
Commercial/SMS policy Owner approves prices/quotas/refunds/consent and sandbox scope; keep real delivery/paid features off #270
Native tools/devices/stores Verify installed toolchain and named devices; signing/upload/public release separately approved #191
Pilot go/no-go Named cohort/operator/support, exact artifact and accepted exclusions; source test count is not release approval #271

A lower-cost model can implement the bounded code/test/doc packages. Planning cannot replace missing infrastructure, owner decisions, real-device/provider evidence or careful local review. Do not close issues solely to make this table green.

Required package completion receipt

Issue/package:
Source branch, head SHA, reviewed base SHA:
Changed files and behavior preserved:
Regression IDs with initial failure and final outcome:
Local commands, versions, date, pass/fail/skip/not-run:
Browser/DB/artifact/provider/device evidence, where applicable:
Review findings, resolution and reviewer/self-review disclosure:
Docs/README/playbook/screenshot updates:
Migration/compatibility and rollback notes:
PR/merge status (only if authorized):
Remaining packages, blockers, dependency updates:

Copyable first builder prompt

Read the Business-First Order at the top of #252 and business acceptance #289.
Choose one ready NOW slice from phase: business-flow. Start with the necessary
#281 safe local harness and #288 noncommercial boundary, then a real role journey.
Use #287 for response semantics, #279 for the reusable plugin and #285 for UI gaps.
Finish local tests/review, affected docs/assets and evidence. Do not start deferred
billing or platform tasks because an old priority/dependency list says to.
No CI checks, deployment, provider activation, fake paid entitlement or model switch.

Handoff planning verification

  • Every open issue has its own specific brief and copyable prompt; no generic-only ticket.
  • Source/test command paths resolve against the inspected baseline; proposed additions are labeled.
  • Hard dependencies reference open work and contain no cycles; coordination links are separate.
  • Historical already-fixed billing/reset/lifecycle/role statements are corrected for current implementation.
  • Updated GitHub bodies are read back; all original issue states remain unchanged.
  • No repository source, workflow/settings, branch, PR, merge, provider or deployment changes occur in this planning run.

Verification receipt (2026-09-13): published and read back all 30 open issue bodies with exact-content comparison; all remain open. All 29 implementation briefs have four uniquely identified work packages and four uniquely identified regression cases. Source/test paths were checked against the 1,307-file baseline and the hard-dependency graph has no missing targets or cycles. Renamed #256/#262 to reflect remaining acceptance rather than already-fixed defects. This was GitHub planning only: no implementation, test-suite execution, source/README/screenshot edits, workflow/settings change, branch, PR, merge or deployment. Local HEAD remains 21a4a804aa57580451edded04736b1f51aef7e48; the pre-existing untracked .claude/scheduled_tasks.lock was left untouched.

Earlier Roadmap and Audit Context (Production-First Order Superseded)

Historical Production Readiness Roadmap

Current policy (2026-09-13)

No CI checks. Everything is validated locally. This includes code review,
formatting, lint, type checks, migrations, all test tiers, security scans,
artifact checks and mobile validation. Do not add hosted jobs, required CI
statuses, synthetic success checks or an Ollama reviewer. GitHub is for source,
PRs, issues and publication, not validation.

Record commands, environment, results, limitations and reviewed head/base SHAs.
Builders merge only with completed local evidence and GitHub mergeability;
reviewer agents never merge. Real staging/provider/device acceptance remains
required where applicable, driven by authorized local operator tools.
Historical evidence and older comments do not override this policy.

Whole-repository audit and issue plan (2026-09-13)

The owner requested everything, not another narrow CI/documentation cleanup. Scope is all 1,307 tracked files at 21a4a804aa57580451edded04736b1f51aef7e48, all 91 pre-audit GitHub issues (20 open/71 closed), the open PR #251, and current workflow inventory. The ten issues below are additional explicit work, not evidence that fixes are already delivered.

Evidence boundary

  • Static syntax parsing completed for all 343 tracked Python files, with no syntax errors. This says nothing about runtime correctness or complete authorization.
  • A tracked Markdown-like scan covered 296 files (176 manual, 120 generated). It found 110 distinct file/relative-target candidates: 44 manual and 66 generated. HTML links, anchors and external links need the planned deeper validator.
  • Reviewed source/command/plan hotspots confirm broken make test, obsolete examples, unsafe cleanup scope, runner/template contradictions, incomplete browser scenario coverage, stale image provenance and unsafe publication behavior.
  • All ten README screenshot histories were checked; dashboard and solver were visually inspected. Do not call the other eight visually reviewed or any image current to this revision.
  • Existing API/web/security/operations findings were reconciled into their current issues. No test suite, fresh screenshot capture, dependency vulnerability scan, PostgreSQL/Docker drill, live provider delivery, device run or deployment was performed in this planning audit. Earlier PR evidence below is historical and was not rerun.
  • Only Pages publication is active. The legacy Playwright workflow is disabled_manually; it is not a CI requirement. No settings changed.

Complete tracked-area ownership

Every tracked path falls into exactly one inventory row. Counts total 1,307. Evidence explicitly distinguishes a static inventory from a completed behavioral/semantic review.

Area Files Inspected evidence / remaining verification Work owner issues
api/ 134 Startup/router/config and scheduling/publication/auth/provider hotspots inspected; all Python syntax parsed. This is not an exhaustive security certification. #253-#258, #260-#270, #286; docs #278/#284
web/ 67 All route declarations and files inventoried; auth/partial/template and browser-harness hotspots inspected. All live views still need the matrix. #261/#262/#264/#266, #279/#280/#285
tests/ 203 Complete file/tier inventory and Python AST pass; Make/harness/playbook/legacy-test source inspected. No suites rerun this audit. #260/#269/#271, #279/#281/#285
mobile/ 643 Platform/client/docs/assets inventory and app/codegen/release guidance inspected; no device/build certification. #191 (all generated/platform files), #277/#278
docs/ 69 Manual docs link/content scan, playbooks and security/runbook review; ten screenshot histories inventoried, two visually sampled. #277-#280, #284
specs/ 93 Every Markdown-like spec included in disposition ledger; source/roadmap supersession checks. Proposals are not new implementation authorization. #277/#282; actual behavior #263/#270/#191
scripts/ 21 All scripts inventoried; agent loops, backup/restore/cleanup/migration/packaging/test helpers statically inspected. #282/#283, #265/#268
.specify/ 13 Constitution, command generation, task templates and branch/discovery scripts inspected. #277/#282
.claude/ 8 Every command included in doc ledger; task-generation policy conflict confirmed. #277/#282
.github/ 2 Only Pages publication and Copilot instructions are tracked; legacy Playwright workflow disabled on GitHub. #269 (Pages), #282 (Copilot); no CI checks
.serena/ 2 Tool configuration/ignore inventory; no policy conformity claim from inventory alone. #282
alembic/ 9 Full migration file inventory and syntax pass; runtime upgrade/rollback/PostgreSQL evidence remains open. #260/#265/#268
config/ 3 Development/production/test configuration inventory; compare with actual runtime env readers. #258/#284
examples/ 7 All example files inventoried; removed roster_cli imports confirmed in retained Python examples. #278/#283
test_data/ 9 Tracked fixture inventory; validate supported schemas/loaders and separate old cricket examples from new Basketball playbook. #278/#279/#281
site/ 3 Public site source/CTA/pricing claims inspected; no fresh published-site browser acceptance. #278/#280; optional features #270
tools/ 2 Local database helper inventory; read/write destination and safety acceptance explicitly assigned. #283/#268
Root files 19 Instructions, README, Make, dependency/packaging/container/pytest metadata inspected; ignore/license/env inventory. #277/#278/#281/#282/#283/#284, #258/#265/#269

Newly explicit deliverables

#277 contains a 176-file completion ledger, including nested legacy specs and all agent/release Markdown. #191 owns the 120 generated Markdown files as part of the complete 643-file native/client cohort. #280 lists all ten existing screenshots; #283 lists every script/database helper. Do not close a broad cleanup with unnamed follow-ups.

Delivery sequence and dependency boundaries

Order Implement / reconcile Exit
0: Safe, truthful baseline #281 supported local test commands/sandbox; #283 safe tools; #277 ledger; #278/#284 correct false current claims; #282 task selection Contributors can run the documented local validation without shared-data/provider risk; current docs do not claim unverified readiness
1: Security foundation Remaining #253-#258 and #261; establish isolated PostgreSQL harness #260 Real-identity negative tests, fail-closed config, auth matrix and local review; already-merged fixes preserved
2: Scheduling and delivery #262-#264, #266, #286; core #279/#285 journeys Persisted rules/roles, atomic claims, safe full-horizon publication, resilient messages and correct multi-actor workflows
3: Release artifact and complete evidence #265/#267-#269; finish #279/#285; capture #280; finish #278/#284/#277/#282/#283 Exact artifact digest, PostgreSQL/restore/alert/security results, both domain walkthroughs and current docs/assets
4: Invited pilot #271 consumes the complete core evidence ledger Owner-approved scope, operator/support/data policy, measured load and stable pilot go/no-go
Optional native/paid #191 and #270, after their API/provider prerequisites Separate codegen/device/store or billing/SMS evidence and explicit enablement approval

This is sequencing, not a requirement to block truthful doc corrections on unshipped features. UI/scenario design can proceed alongside backend fixes; final acceptance/capture waits for the behavior it claims. Do not introduce circular ticket dependencies by treating every coordination link as a hard prerequisite.

Required decisions, not invented assumptions

Name the release/operator/support owner, hosting region/provider and budget, pilot cohort, retention/RPO/RTO targets and supported browser/device/locale matrix. Confirm Church/Basketball eligibility/safeguarding/rest rules and publication override/full-horizon policy under #279/#286. Keep optional paid/SMS/native features excluded until explicitly accepted. Re-estimate remaining slices only after capacity/owners are assigned; no copied historical completion percentages or promised launch dates.

Closure rules

  • Every tracked area has disposition/review evidence and every confirmed residual defect has an explicit issue; inventory alone is not substantive sign-off.
  • Both six-week domains are prominent in README and have accurate API/unit/browser/manual traceability.
  • All current screenshots have a repeatable local capture command and revision/viewport/scenario provenance.
  • Supported local commands cover the declared test matrix; skipped/opt-in scopes, static/type debt and environment limits remain visible.
  • Docs, examples, public site, instruction generators, GitHub issues and release records agree; retired history cannot drive new work.
  • Core P0/P1 acceptance is satisfied with source, artifact and operator evidence before pilot approval; optional scope stays explicit.
  • No CI checks, required statuses or hosted code reviewer are reintroduced. No issue closes based solely on a banner, test count or missing CI run.

Scope and decisions

Deliver an invited web/API scheduling pilot first. Keep paid billing, SMS delivery
and native-store release behind their own acceptance gates. Mounted endpoints
still require authorization fixes even with outbound providers disabled.

The owner must choose release operator, deployment region/provider, budget,
retention/RPO/RTO, pilot cohort and support coverage before the affected work.
This roadmap does not authorize deployment, live messages, charges or store release.

Delivery phases and remaining work

Phase Work items Exit evidence
A: Security #253 organization lifecycle; #254 tenant isolation; #255 membership; #256 billing object authorization; #257 SMS scope/signatures; #258 configuration; #261 browser protections Reviewed fixes and local negative-path tests; no unresolved core security blockers
B: Core workflows #260 PostgreSQL parity; #262 reset delivery; #263 persisted constraints; #264 atomic claims; #266 reliable notifications Local API/browser church and basketball playbooks, PostgreSQL races and real delivery evidence
C: Operability #265 reproducible artifact/staging; #267 monitoring; #268 restore/retention; #269 local security scans Artifact digest, local operator validation, alert/restore/rollback evidence
D: Pilot #271 release acceptance/load/pilot Release matrix, accepted risks and owner go/no-go after an agreed stable pilot
E: Optional #270 billing/SMS acceptance; #191 native codegen/device release Separate provider/device evidence and explicit enablement approval

#259 now tracks local validation/evidence hygiene, not an AI/CI gate. It must not
block delivery waiting for a hosted workflow, credential or required check.

Verified merged milestones through main 21a4a80

Dependencies

Start the remaining security fixes and local PostgreSQL harness in parallel.
Membership/browser protections precede reset acceptance. Tenant/constraint/DB
work precedes atomic claim acceptance. Configuration and database readiness
precede artifact validation. Artifact and messaging recovery precede operations
drills. #271 consumes all core release evidence; optional tracks do not block a
safely scoped web/API pilot.

Previous 55-89-day totals included stale work and a rejected hosted-gate rollout.
Do not reuse them as a commitment. Re-estimate only remaining acceptance criteria
after owners and capacity are assigned; record dependencies, uncertainty and
external provisioning time separately.

Definition of done

  • Core P0/P1 security and workflow issues are resolved with linked local evidence.
  • Local formatting/lint/types, migrations, test tiers and code review are complete
    for the pushed source. Run make test-all and mobile validation when applicable.
  • PostgreSQL release journeys, concurrency and migration parity are verified locally.
  • Invitation/reset messages and recovery paths work without debug-token shortcuts.
  • The release artifact has recorded source SHA/digest, alert/restore/rollback/load evidence.
  • The owner accepts scope, support, data policy, residual risks and release go/no-go.
  • Optional features remain unavailable until their separate acceptance passes.
  • No CI checks, required CI statuses or hosted reviewers are introduced.

Evidence and maintenance

Use docs/ROADMAP.md, docs/TESTING.md and docs/ai-pr-review.md as the current guides.
Reconcile each issue with merged source; retain dated comments as history, not
active blockers. Local results are evidence reports, not GitHub attestation.
Never claim independent review for a builder's self-review or label skipped work
successful. Distinguish clean-environment failures from borrowed-environment drift.

Broader follow-through now has explicit issues #277-#286 and the complete ownership
matrix above. #284 owns production config/runbook claims with #258/#265;
#281 owns local tooling, #282 agent consistency, #277 all retained documents,
and #271 consumes their release evidence.
Keep historical marathon issues closed unless a specific regression is confirmed.

Policy refactor completion (2026-09-13)

PR #276 merged as 21a4a80. Local evidence for
head 2bcc534: 1428 Python tests passed,
21 skipped, including 33 Playwright; 65 Flutter tests passed. Scoped mypy,
Black, Ruff, workflow/shell syntax and fresh SQLite migration checks passed.
Full-API typing debt and unavailable local PostgreSQL are documented limitations,
not passed validation. No CI checks or workflow runs occurred for this PR.
Only static Pages publication remains, separate from validation.

Audit planning receipt (2026-09-13)

  • Created P1: Reconcile every document and legacy spec with current source #277-P1: Prevent incomplete and destructive schedule publication #286 with source evidence, implementation slices, acceptance criteria, suggested owner roles, dependencies and local validation requirements.
  • Expanded all 20 pre-audit open issues, including this roadmap; preserved completed partial fixes and the open status of remaining work.
  • Added policy-supersession notices to 31 closed CI-related issues without reopening or deleting their history. Clarified the bounded completion of P1: Make local validation and review evidence reproducible #259 and the historical screenshot evidence in Sprint 11 tracking — web app full e2e #121.
  • Read back all changed issue bodies and verified immutable source links against the tracked file inventory. No original issue state was changed.
  • GitHub confirms main protection returns 404: Branch not protected and rulesets returns []. These are configuration observations, not access errors. No protection/ruleset/workflow settings were changed.
  • Repository source, README and screenshots were not edited in this planning-only run. No branches, commits, PRs, merges, deployments or test-suite runs were performed. The pre-existing untracked .claude/scheduled_tasks.lock was left alone.

This receipt completes the requested audit-to-GitHub planning, not the implementation or production acceptance described above.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestphase: platform-laterPlatform, release and native work deferred until business-flow acceptance.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions