Skip to content

P1: Accept complete Church and Basketball day-to-day business flows #289

Closed

Description

@tomqwu

Business-Flow Acceptance: Church and Basketball

Current owner priority (2026-09-13): a complete, usable business flow and day-to-day operations for every role come before billing or platform production readiness. Parent roadmap: #252. This issue is the next business milestone; #271 remains a separate later production/pilot gate. All tests and code review run locally. No CI checks.

Definition of the Business Milestone

Starting from a fresh local organization with fictional data, a scheduling administrator/team manager and every supported member role can operate a six-week roster through the normal browser, handle daily exceptions, and roll into week seven without API/DB repair, fake paid entitlement, lost future shifts or falsely confirmed responses. Run the Church and Basketball organizations together to test isolation.

This is functional business acceptance, not a production deployment, safety certification, live delivery guarantee or approval to run a real church/game from simulated evidence. Physical service/game execution, safeguarding, medical/league clearance and tactical decisions remain human responsibilities.

Canonical Starting Sources

Baseline 21a4a804aa57580451edded04736b1f51aef7e48: Church guide, Basketball guide, plugin guide, shared workflow, browser runner, role definitions.

The API lifecycle creates twelve primary/secondary events. The current browser test creates only six primary events, seeds people and five events through the API, and selects one assignee plus a reserve. It does not prove the complete twelve-event schedule or the day-to-day flow of each qualification. Close this gap rather than calling current green tests full business acceptance.

Permission Boundary

Keep two actual access levels: admin and volunteer. A worship leader, children's leader or coach is a business/scheduling role, not a new permission level. Do not automatically grant leadership roles admin or invent department-scoped RBAC. Test every scheduling role as a volunteer; use separate explicitly authorized admin identities for coordination. Human approvers need no invented account type.

Role-by-Role Operating Matrix

Every account row runs common member actions: invitation/login, own availability, schedule review, explicit accept/decline, qualified cover, notification/calendar review and recovery. Add the responsibilities below. Parameterize every named qualification; do not count one generic volunteer run as evidence for all roles.

Actor Actual access / qualification Daily responsibility and observable exit
Church scheduling administrator admin Onboard/qualify people, maintain all services/rehearsals, review gaps and unanswered responses, publish only a valid horizon, arrange cover, roll forward
Worship coordinator volunteer + worship_leader Review rehearsal/service commitments, respond, report absence, arrange qualified leadership cover through the authorized workflow; cannot publish
Musician volunteer + musician Respond to music/rehearsal slots; two distinct music slots stay covered, no double-booking
Sound operator volunteer + sound Respond to rehearsal/service technical duty; last-minute cover must retain sound qualification
Welcome/usher member volunteer + usher Respond to the specific welcome shift; two different people fill the two required positions
Children's leader volunteer + children_leader Respond and report availability; removal of qualification prevents future allocation until an admin confirms eligibility again
Church reserve volunteer + the slot's qualification See only eligible current open/swap work; successful cover transfers exactly one assignment and requires explicit commitment
Ministry approver Human responsibility, not additional RBAC Verify suitability/safeguarding and authorize operational changes outside the solver; record a manual checkpoint, never infer approval from a role string
Basketball team manager admin Maintain games/practices, positions/staff/reserves, response queue, postponements and full rolling schedule
Coach volunteer + coach Review own coaching commitment and practice/game readiness; withdraw/request qualified cover without implicit manager powers
Point guard volunteer + point_guard Respond to own position; absence/injury uses qualified position cover
Shooting guard volunteer + shooting_guard Respond to own position; cannot fill another position solely because they are a player
Small forward volunteer + small_forward Respond to own position and cover only explicitly qualified work
Power forward volunteer + power_forward Respond to own position and see correct changed schedule
Center volunteer + center Respond to own position; cannot silently replace the missing point guard
Scorekeeper volunteer + scorekeeper Respond to game/practice duty; last-minute withdrawal leaves an actionable staffing gap
Basketball reserve volunteer + the slot's qualification Claim/cover only qualified available slots; competing claims have one winner
Coach/manager human check Existing actor, outside-app responsibility Verify attendance, league/medical clearance, venue arrangements and game tactics without claiming the app enforces them

Weekly Operating Cycle

  • Monday: Coordinator reviews the next six weeks, vacancies, unanswered/declined assignments and upcoming changes; each role reviews their own commitments.
  • Tuesday: Members enter absences or changed availability; coordinator follows up on unanswered work and qualifies replacements.
  • Wednesday: Rehearsal/practice roster is usable by every assigned role. Physical attendance/execution is a separate human checkpoint.
  • Thursday: Coordinator changes requirements/times where needed, solves the complete remaining horizon and compares the candidate with the live roster.
  • Friday: Resolve shortages, publish, deliver in-app/local-mail updates and collect explicit responses. An unacknowledged default confirmed row must not count as a response.
  • Service/game day: Member decline, late absence and reserve cover are recoverable through the app, with consistent original/reserve/coordinator views.
  • Afterward: Review roster workload and outstanding follow-up, preserve completed history, add week seven and repeat the operating loop. Scheduling counts are not attendance or playing minutes.

Shared Business Journeys

Each BO ID runs for both domains with actor/qualification subcases. Existing CH-01..CH-08 and BB-01..BB-08 remain stable; new BO IDs extend, not rename or silently replace them.

ID Workflow Required oracle / negative case Implementation owner
BO-01 Fresh start without commerce Browser org/admin setup, 14 members and a replacement, no card/trial/subscription seeding; foreign-org takeover denied #255, #288, #285
BO-02 Invite and qualify every role UI creates/redeems invites and manages scheduling qualifications; expired/replayed invites recover without role escalation #255, #262, #285
BO-03 Daily availability Every role records one-off and recurring absence; solver respects it; another member cannot edit it #254, #263, #285
BO-04 Full six-week plan Twelve events: six primary plus six rehearsal/practice sessions, seven distinct qualified people each; fair baseline and no overlaps; incomplete/stale publication rejected #263, #286
BO-05 Response and follow-up loop Pending versus explicit accepted/declined is truthful; coordinator resolves unanswered/declined/swap work; login or notification read is not acceptance #287, #285
BO-06 Qualified replacement Original declines/requests swap, qualified reserve covers, coordinator sees resolution; wrong-role/absent/foreign/stale/competing attempts cannot corrupt roster #264, #287
BO-07 Change/cancel safely Change one occurrence versus intended series scope; move/cancel affects only intended future commitments; replaced actions rejected; response resets when commitment changes #286, #287, #285
BO-08 Rolling week seven Advance the scenario clock through a completed week, add seventh primary/secondary sessions and maintain the next six-week horizon; retain prior history and unrelated future commitments #286, #279
BO-09 Communication and recovery In-app recipient/coordinator state agrees; actual local captured invitation/reset/change/reminder content and links are usable; failed/disabled delivery is not labeled delivered #262, #266, #285
BO-10 Calendar and time Personal calendar matches current published dates/times, moved/cancelled entries handled without duplicates or foreign assignees; exercise a non-UTC/DST case #254, #285
BO-11 Account/session recovery Every permission level can log out/in, change password and follow the real captured reset link; expired/replayed/stale sessions fail safely #255, #261, #262
BO-12 Two-org and per-role separation Church/Basketball accounts isolated; each member manages only their own work; volunteers including leaders/coaches cannot invite/admin-publish or view private foreign data #254, #255, #285

Domain-Specific Extensions

  • CH-D01: Last-minute sound or children's-role withdrawal is visible as a real gap; cover must have the exact qualification and be available.
  • CH-D02: Admin removes an externally revoked ministry qualification. Future candidate/live roster is flagged/repaired without inventing safeguarding approval or silently rewriting completed history.
  • CH-D03: Holiday/additional service changes one occurrence/headcount as intended; compare/publish/notify/respond preserves other future weeks.
  • BB-D01: Multiweek injury absence removes the player throughout the recorded interval; return requires deliberate availability/eligibility update, not medical inference.
  • BB-D02: Coach and scorekeeper each withdraw in separate cases; role-correct cover works and player slots remain complete.
  • BB-D03: Venue/game postponement updates the schedule/calendar and requests new responses; venue/opponent negotiation stays a named human checkpoint.
  • BO-DUAL: A multiskilled person never fills two slots in one event, and adjacent legal sessions remain allowed.

Shared-player multi-team eligibility, automated venue collision, league enforcement, safeguarding certification, tactical substitutions, playing minutes and an attendance/check-in module are not silently implied by this single-organization roster milestone. Record unsupported operations explicitly; ask for scope approval before building a new subsystem. Do not label missing in-app steps in BO-01..12 as manual to evade acceptance.

Pluggable Local Test Contract

  • P1: Complete pluggable church and basketball acceptance coverage #279 owns discovery/runner extension. Keep validated typed domain fixtures and named reusable actions/checkpoints. Do not add arbitrary executable strings, a generic workflow DSL, or hard-coded separate Church/Basketball domain lists.
  • Produce a coverage manifest: domain, BO/CH/BB ID, role, precondition, UI action, expected persisted/member/coordinator result, automated/manual tier, screenshot and tested SHA. Missing mandatory IDs/roles must fail validation, not disappear by collection filtering.
  • Maintain a fast API/state-machine tier, real unit invariants, and Playwright role workflows. At least one complete onboarding/setup flow per domain uses normal UI (not API/DB mutation). Other focused tests may use clearly labeled fixtures outside the action being claimed.
  • All twelve events and every qualification are exercised in browser acceptance; every actor/context uses both 360px and 1440px coverage. Relevant failure controls get overlap/hit-target, keyboard/focus and JavaScript-error checks, not just page-width assertions.
  • Use fictional per-run owned data/ports and an owned local mail sink. Keep real Stripe/SMS/external email disabled. No API-token/debug-token shortcut for invitation/reset acceptance.
  • Use the actual selected local DB engine for atomicity tests; P1: Prove local database correctness; defer production parity #260's minimal owned PostgreSQL harness is allowed when needed to validate the chosen locking approach. This is local correctness evidence, not a requirement to deploy a platform or claim cross-engine parity.
  • Fresh login/refetch and app restart must preserve accepted business state. Multiworker/HA delivery/load/security certification remains later; ordinary lost responses or missing committed in-app messages are current bugs.
  • Run API and browser suites in separate processes. Existing commands after P1: Repair local test entry points, coverage and isolation #281 safe preflight:
poetry run pytest tests/unit/test_playbook_plugin.py tests/unit/test_solver_role_slots.py -q
poetry run pytest tests/api/test_domain_playbooks.py --playbook church --playbook basketball -q
poetry run pytest tests/e2e/test_domain_playbooks.py --playbook church --playbook basketball -q
make test-unit
make test-all

These existing commands are entry points, not a claim the expanded cases already exist or pass. Include the third-party food-bank plugin compatibility check from #279; native tests run when affected, not as a store-release prerequisite.

Bounded Work Packages

  • FLOW-1: Publish the role/action and BO/CH/BB coverage manifests, gap inventory and local noncommercial acceptance profile; assign every missing user operation to P1: Audit every web journey for usability and failure recovery #285 or a concrete focused owner.
  • FLOW-2: Complete the Church role-by-role day/week cycle, then the Basketball cycle using the same plugin contracts, with state/negative-case oracles.
  • FLOW-3: Complete late-change/response/replacement/rolling-week-seven and two-organization tests; fix actual missing behavior in its owner issue rather than relaxing acceptance.
  • FLOW-4: Run and inspect the complete local unit/API/browser acceptance, produce current role/workflow screenshots and README/playbook instructions, obtain owner business acceptance and attach exact evidence.

This issue coordinates acceptance; do not duplicate the source implementations owned by #279/#285/#287/#288/#263/#264/#286/#266. Write small PRs per ready work package; not one giant milestone PR.

Business Sign-Off Checklist

  • BO-01..BO-12 and all domain extensions have domain/role-specific results and required manual human checkpoints are explicitly recorded.
  • All supported in-app daily operations are achievable through normal UI with no hidden API repair or paid-plan shortcut.
  • Both domains complete all twelve events, disruptions and rolling week seven without missing roles, double-booking, wrong absences, future-shift loss or false acknowledgement.
  • Unit, API/web and Playwright/plugin tests and local code review pass on the recorded revision; skips/failures/unrun scopes are visible.
  • README, playbook role guides, commands, coverage map and captured phone/desktop screenshots match the demonstrated flow.
  • Owner accepts the business workflow and names remaining product limitations. This does not close P2: Run production release acceptance after business flows are accepted #271, authorize a deployment or certify external delivery/production readiness.

Stop Conditions and Receipt

Stop a slice for unresolved role/publication/response semantics, a missing safe local backend, or a UI operation that would require an unapproved subsystem. Do not wait for billing/cloud/platform tickets merely to test a role journey. Record package/test IDs, implementation links, command/version/date, head/base SHA, outcomes, screenshot paths, human checkpoints and deferred platform scope. A fresh local reviewer checks that every role was actually exercised and fixtures did not bypass the claimed step.

Copyable Builder Prompt

Implement the next ready business-flow work package from #252 using this issue as the acceptance gate.
Start with the narrow #281 safe-test foundation and #288 noncommercial boundary, then deliver one Church
or Basketball role workflow through the actual UI with its unit/API/Playwright regressions.
Use #287 for response semantics, #279 for plugin coverage and #285 for UI gaps. Preserve all other
roles/weeks/tenants and record exact evidence. No CI checks, billing buildout, production deployment,
real provider delivery or automatic model upgrade. Finish affected docs/screenshots for the slice.

Activity

  1. added
    enhancementNew feature or request
    phase: business-flowCurrent Church/Basketball business-flow work; execute only the active slice in each issue.
    on Sep 13, 2026
  2. tomqwu commented on Sep 13, 2026

    @tomqwu
    OwnerAuthor

    Prerequisite receipt: PR #290 merged to main as b957a2b52e2476d8764ba1ad5b6a9ac96d357990.

    This completes two foundations for the business milestone:

    • Safe local seven-tier execution with provider credentials removed and external network rejected.
    • Default-off billing/paid-SMS boundaries across API, tasks, and web.

    Current verified playbook evidence:

    • API: Church and Basketball six-week scenarios passed.
    • Browser: basketball-360, basketball-1440, church-360, and church-1440 passed.
    • Complete local result: 1,442 passed, 21 skipped on pushed head a5c0dbcea69852642d3a3d422f92a8df2d01c9b1.
    • No CI check, Ollama code review, provider call, or deployment occurred.

    This is not FLOW-1 through FLOW-4 completion. Keep #289 open for the BO/role coverage manifest, normal-UI onboarding and qualification, truthful pending/accepted/declined behavior, qualified replacement races, change/cancel and week-seven rollover, two-org per-role acceptance, owned mail/calendar recovery, accessibility, and fresh 360px/1440px screenshots. The existing screenshots were not refreshed by PR #290 and must not be cited as current acceptance evidence.

  3. added a commit that references this issue on Sep 13, 2026
  4. tomqwu commented on Sep 13, 2026

    @tomqwu
    OwnerAuthor

    FLOW-1 progress receipt: PR #291 merged as commit 5ccff21. The new manifest explicitly records actors, preconditions, operations, expected results, tiers, evidence, and honest automated, partial, or blocked status for BO-01 through BO-12 plus CH/BB-01 through CH/BB-08. It deliberately does not claim incomplete workflows are done: BO-08 and BO-09 remain blocked, while normal-UI role onboarding and incomplete-publication safety remain partial. Exact-head local evidence: 1,449 passed and 21 skipped. Keep #289 open while those rows are implemented and promoted.

  5. tomqwu commented on Sep 13, 2026

    @tomqwu
    OwnerAuthor

    FLOW-1 partial implementation receipt (PR #292, merged as 34996c1c9222c9b70868c3a545f826d10d263e49):

    • Church and Basketball member onboarding now runs through browser invitations and acceptance instead of API member seeding.
    • All fourteen participants per domain receive explicit scheduling qualifications without gaining administrator access.
    • The resulting end-to-end flow still creates, solves, reviews, publishes, responds, and swaps at phone and desktop widths.

    Local evidence for pushed head cacff48095e86930bd40727bd9a32d99f735f2da: make test-all completed with 1,467 passed and 21 skipped. GitHub reported MERGEABLE/CLEAN before merge.

    This issue remains open. Remaining FLOW-1 prerequisites and FLOW-2 through FLOW-5 acceptance work are not complete yet.

  6. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    Follow-on implementation receipt: PR #293 merged as 73b5a99.

    The onboarding and role-qualification flow now sits on an atomic organization bootstrap and invitation-only membership model. The full local matrix passed 1,490 tests with 21 intentional skips, including 33 Playwright tests and both Church/Basketball browser workflows at 360px and 1440px. This is supporting evidence only; the issue stays open until all of its own acceptance criteria are evidenced.

  7. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    Business-flow receipt: scheduling tenant boundaries

    PR #294 merged as f6da81a73b1a670c106c33d8fadc72eb593e95d6.

    Completed the #254 NOW slice across Church/Basketball journeys: explicit mounted-route auth policy, real-JWT two-tenant coverage, actor-derived event/conflict/availability/solution scoping, safe assignment children and identity-bearing metrics, exact person/team/org exports before serialization, synchronized web/mobile callers, and maintained docs.

    Local evidence on pushed head e9395eeb0409c924f879d452504606d44234407f: make test-all 1,497 passed/21 intentional skips; make test-mobile 65 passed; Black/Ruff/diff checks passed; both domain browser playbooks passed at 360px and 1440px. Self-review findings and remaining PostgreSQL-only work are recorded on #254. No CI, Ollama review, provider activation, or deployment.

  8. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    Saved-constraint and assignment-role NOW slice completed in PR #295, merged as a0f27354f12e7270741d0f560054a12a8ed2da52. Exact-head local evidence: 1,515 passed / 21 skipped, including 33 Playwright tests and both domain playbooks at 360px and 1440px. Saved caps/rest/cooldown now execute, invalid rules fail explicitly, and API/CLI roles persist. No CI or Ollama review. #263 remains open only for retained #264/#286 eligibility/allocation integration.

  9. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    #286 completion receipt

    • Issue: P1: Prevent incomplete and destructive schedule publication #286
    • PR: Protect full-horizon schedule publication #298
    • Merge commit: 6fdd8bafb75ab38b8db0ca17e34d174217c94180
    • Validated head/base: eae3e9138cf5a4f023c4ca2786e076eb3a890739 / 784e314f4f8aff66173462f559a209d6ad488d1e
    • Acceptance covered: BO-04 incomplete/stale publication rejection; BO-07 response reset and safe change/rollback semantics; BO-08 full-horizon preservation and week-seven rollover; Church/Basketball shortage-and-repair paths.
    • Local evidence: make test-all (434 unit passed / 21 skipped, 490 API, 16 CLI, 337 integration, 238 web, 1 contract, 33 Playwright); make test-mobile (65); PostgreSQL 16 concurrency (9); fresh PostgreSQL Alembic upgrade through e7f9a1b3c5d7; Black/Ruff/scoped mypy/diff/secret checks passed.
    • Review repairs: HTMX 409 rendering, role-specific shortage messages, changed-role response coverage, independent persisted hard-constraint revalidation, and typed query boundaries.
    • Screenshots: existing layout screenshots remain current because this slice changed publication behavior and reused the existing alert surface; no page composition changed. Expanded FLOW-4 role/workflow captures remain open under P1: Accept complete Church and Basketball day-to-day business flows #289.
    • Deferred: live provider delivery, billing, deployment, and broader platform release work were not activated.
  10. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    Implemented BO-01 browser bootstrap in PR #299, merged as e3d8bb1548b215389f6a003ccd5d721905e77c4e.

    Evidence on pushed head 6e05e560399188e408434c9cb5aefa1cd5bce902:

    • Church and Basketball each create the organization/first admin through normal signup at 360px and 1440px.
    • Each flow invites and accepts 14 baseline members plus one qualified replacement through the UI.
    • Fresh 0 of 4 onboarding, tenant-scoped organization visibility, disabled Billing navigation, qualification editing, full solve/publish/response/swap flow, and responsive fit are asserted.
    • make test-all: unit 435 passed/21 skipped; API 490; CLI 16; integration 337; web 238; contract 1; Playwright 33.
    • make test-mobile: 65 passed.
    • Local review only; no hosted tests and no Ollama code review.

    This completes BO-01 but does not close the broader issue. Repeated-event browser creation and BO-03 through BO-12 remain tracked work.

  11. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    BO-03 is complete via PR #300, squash merge 1ff1337. Every fixture-discovered Church and Basketball role now records one-off Wednesday time off and a recurring Sunday exclusion through the browser at 360px and 1440px. The workflow proves a peer member receives 403 and cannot mutate either record, then verifies the solver excludes every blocked actor with zero hard violations.\n\nEvidence on exact pushed head 29b60be: focused domain E2E 8 passed; make test-unit 435 passed and 21 skipped; make test-all API 490, CLI 16, integration 337, web 238, contract 1, Playwright 37; make test-mobile 65. All review and tests ran locally; no hosted tests or Ollama code review.\n\nThis closes only BO-03. The broader issue remains open for BO-04 onward.

  12. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    BO-04 is complete via PR #301, squash merge f265c40. The normal admin browser journey now creates all six primary and six rehearsal or practice events for Church and Basketball at 360px and 1440px. It reviews a visible 84-assignment, zero-hard-violation solution and independently proves exact role counts, distinct qualified assignees, no overlaps, and balanced interchangeable loads before publication. Existing API and web regressions prove incomplete and stale candidates cannot replace the live roster.\n\nEvidence on exact pushed head dc32a2b: TDD red was 6 events instead of 12; focused full-plan Playwright 4 passed; complete domain module 8 passed; make test-unit 435 passed and 21 skipped; make test-all API 490, CLI 16, integration 337, web 238, contract 1, Playwright 37; make test-mobile 65. Church mobile and Basketball desktop full-plan screenshots were inspected. All review and tests ran locally; no hosted tests or Ollama code review.\n\nThis closes only BO-04. BO-07 and later business operations remain open.

  13. 12 remaining items

  14. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    Roadmap receipt: local validation prerequisite #281 is complete via PR #314 (merge e38792f). The final source-bound run on f66241b recorded 1,661 passed / 21 skipped, including Church and Basketball API/browser coverage and 72 Playwright tests. Next active package: #283 safe/current milestone tooling.

  15. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    Roadmap receipt: maintenance/tool safety #283 is complete via PR #315 (merge 2ce04fb66e6645717ce62f05cbf6015182572277). Exact-head local validation on e20af73edc3e62aca6920a4f4c97469cda5f0c18 recorded 1,694 passed / 21 intentional skips, including 72 Playwright tests. The package retired unsafe global cleanup/ad hoc migration/stale demo paths, made DB tools immutable read-only, retained interruption diagnostics, and repaired an HTMX assignment race found by the first full run. Next active package: #282 local-only agent runner and template alignment.

  16. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    Completion receipt

    Merged PR #316 into main at 2c25f99. Tested source: d632d13; reviewed base: 2ce04fb.

    • 282.1 / T282-01: fake Git, GitHub CLI, and agent fixtures cover plan/review/build behavior, dirty worktrees, forbidden mutations, unsupported mode, and missing prompt.
    • 282.2 / T282-03: recursive versioned work-item discovery skips blocked/completed/deferred items, resolves hard dependencies, selects deterministically, and SpecKit only creates a codex/ branch with explicit opt-in.
    • 282.3 / T282-02 and T282-04: builder completion requires owned diffs, a clean source-bound local report, current reviewed head/base SHAs, and GitHub MERGEABLE/CLEAN; failed commands, stale/failed evidence, and DONE-only output fail closed.
    • 282.4: both Claude and Gemini adapters, SpecKit generators/templates, README, tooling index, examples, and operator docs are covered and reconciled.
    • No CI check, hosted reviewer, Ollama code review, model auto-upgrade, live agent run, provider activation, deployment, branch deletion, or real-data action was introduced.

    Validation on tested source:

    • Focused runner/policy/tool tests: 54 passed.
    • Unit suite: 530 passed, 21 explicitly skipped.
    • make test-all: 1,710 passed, 21 skipped, 0 failed, 0 errors.
    • Seven passed tiers: unit 530/21 skipped; API/security 505; CLI 16; integration 338; web 248; contract 1; Playwright 72.
    • Report: test-artifacts/local-validation/20260914T203506.257431Z-27095-14d9ac21/report.json (source SHA matched; tracked tree clean).
    • Black, Ruff, runner-module mypy, shell syntax, diff check, and secret scan passed.
    • Repository-wide mypy api remains at its pre-existing 830-error legacy baseline; this package changed no api modules.
    • Local self-review was used and is labeled as such; one example-text typo was fixed before the final full suite, with no unresolved findings.
  17. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    Business milestone receipt - public product package

    Issue #278 is complete via PR #317.

    • Source 94fb4025f9d468d72e87e4e45a1de561c3e72421 -> merge 024e45cfdd1da68dcc13888b7f58d991a605b264
    • Local validation: 1,721 passed, 21 intentionally skipped, 0 failed/errors
    • Church/Basketball README and public-site entry points, maintained CLI/API examples, route inventory, badges, and noncommercial/local-validation boundary are now aligned.
    • Responsive inspection passed at 360px and 1440px.
    • No CI/Ollama review evidence and no provider/deployment activation.

    The next active work stays in the business-flow lane. #277 remains open for its bounded current-doc slice and later full documentation ledger; this receipt does not claim that broad ledger is complete.

  18. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    Completion receipt for PR #318 (merged as 34991bd5660c6422a884f40d5b3f9c71a4a5608e; reviewed head 8ef3d7e79ce92b6d96ac4a782f31364e3d30b960, base 024e45cfdd1da68dcc13888b7f58d991a605b264).

    • make test-all: 1,731 passed, 21 skipped, 0 failed/errors; exact-head report test-artifacts/local-validation/20260914T220552.562377Z-84297-1aec53ae/report.json.
    • make test-postgres: 8/8 on PostgreSQL 16.14; exact-head report test-artifacts/postgres-validation/2026-09-14T220546.824527-0000-83945-721f1f41/report.json.
    • Two parallel PostgreSQL harness invocations each passed 8/8 with distinct owned containers/databases; no labeled containers remained.
    • Black, Ruff, and mypy for changed modules passed. Whole-repo mypy remains a known legacy backlog: 830 errors in 39 files.
    • Local self-review found no blocking findings after the stale documentation-test assertion was corrected. This was self-review, not independent review.
    • GitHub reported MERGEABLE / CLEAN before merge. No hosted CI test, Ollama review, provider action, deployment, or mobile change was involved.
  19. tomqwu commented on Sep 14, 2026

    @tomqwu
    OwnerAuthor

    Business-flow roadmap receipt: browser request integrity and safe client identification landed in PR #319 as merge 35fd3714e261e06a4b2583e14a4bcd69f97b6a2f. Exact pushed-head local evidence is 1,747 passed / 21 intentional skips, including all 73 Playwright cases and both Church/Basketball workflows. The package protects BO-01/02/11/12 browser mutations and auth entry points without changing the noncommercial scope or activating providers. GitHub reported MERGEABLE / CLEAN; review was local self-review, not independent review.

    #261 stays open for distributed/multiworker and deployed proxy/TLS acceptance. Those are later platform controls and do not invalidate the completed local business-flow behavior. #289 remains open pending final roadmap/document reconciliation and explicit owner business acceptance; this comment does not invent that sign-off.

  20. tomqwu commented on Sep 15, 2026

    @tomqwu
    OwnerAuthor

    FLOW-4 technical evidence refresh on merged main package PR #320: exact tested head 42cb887ec5a0d3ab8c6bf6a6b79e373501a267f8 ran the complete local suite with 1,779 passed / 21 skipped / 0 failures/errors, including 506 API/security, 261 web, and 73 Playwright tests. Both Church and Basketball passed every responsive role, availability, late cover, qualification change, postponement/holiday change, two-org isolation, recurrence, complete six-week workflow, week-seven rollover, local recovery/notification mail, calendar, account recovery, and request-integrity journey at the declared widths. README scenario links and the 44-image manifest remained current under the screenshot drift tests.

    The technical checklist is evidenced; this issue remains open only for the explicit owner business acceptance and naming of remaining product limitations. I am not fabricating that human sign-off. Per the owners latest instruction to finish all issues, I am continuing the authorized local platform implementation without treating this as deployment/provider authorization.

  21. tomqwu commented on Sep 15, 2026

    @tomqwu
    OwnerAuthor

    FLOW-4 automated acceptance receipt (current main 779074f3a806f318b9edebf3a77d92b0a1573f16): the complete local matrix on tested head f1c2c18e1c9e10451d4ed09132559a0f38475357 passed 1,847 / skipped 21 / failed 0, including 73 Playwright tests. Both Church and Basketball run BO-01..12 and CH/BB extensions across every declared role at 360px and 1440px, twelve-event six-week schedules, response truth, qualified cover, requirement/time/cancel changes, two-tenant boundaries, local invitation/reset/change/reminder mail, calendar/DST behavior, and week-seven rollover. docs/playbooks/coverage.json has 35 automated rows; the current screenshot manifest has 44 phone/desktop images and passed source-drift validation. README and both role guides expose the workflows and current evidence.

    No hosted CI, Ollama review, paid entitlement, provider delivery, deployment, safeguarding/medical/league certification, or production readiness is inferred. Automated/local implementation acceptance is complete. Per this issue's final checklist, it remains open only for repository-owner business acceptance and confirmation of the documented product limitations; #271 stays separate.

  22. tomqwu commented on Sep 15, 2026

    @tomqwu
    OwnerAuthor

    Deferred-safety receipt

    After the automated Church/Basketball milestone, PR #326 completes the resumed #257 SMS security package without changing the scheduling business flow. Exact-head local validation passed 1,875 tests with 21 skips, including 73 Playwright cases and both playbooks.

    SMS remains disabled by default; no live provider action or commercial enablement occurred. This receipt does not replace the owner business-acceptance decision still required for #289.

  23. tomqwu commented on Sep 15, 2026

    @tomqwu
    OwnerAuthor

    Current-head business-flow verification receipt

    The completed Church/Basketball implementation remains green after the final solution-export and documentation reconciliations.

    • Current tested source: e6bc24b6a0df4b585f3ed797e90ec22435619872, merged by PR Correct stale API, environment, and mobile guidance #334 as 924fc0351166bebb9870fed0e44b737ff7234bb5.
    • make test-all: 1,985 passed / 21 skipped / 0 failed / 0 errors, including all 73 Playwright tests.
    • Exact SHA-bound report: test-artifacts/local-validation/20260915T183125.899040Z-48293-4928b80a/report.json with tracked_tree_clean=true.
    • Both pluggable Church and Basketball playbooks passed mobile and desktop variants for every-role availability, exact-qualified late cover, eligibility changes, occurrence/series changes, two-organization isolation, six-week browser operation, week-seven rollover, calendar behavior, and local mail/recovery.
    • make validate-screenshots passed. README/playbook screenshots remain tracked and valid.
    • PR Add tenant-scoped solution ICS export #333 added tenant-scoped solution ICS export and updated the generated OpenAPI/Dart client; PR Correct stale API, environment, and mobile guidance #334 corrected stale API/environment/mobile guidance without weakening business acceptance.
    • make test-docs passed for 188 manual / 138 generated documents.

    This completes the currently automatable local evidence and documentation reconciliation. Keep #289 open for the final criterion: owner business-workflow acceptance and a named list of remaining product limitations. No automated result is being represented as that owner decision. No hosted CI, Ollama code review, provider action, deployment, or paid activation occurred.

  24. tomqwu commented on Sep 15, 2026

    @tomqwu
    OwnerAuthor

    Owner acceptance decision requested

    All automatable and documentation criteria are now checked in this issue. The remaining unchecked items are FLOW-4 only because it includes owner acceptance, and the final owner sign-off line.

    Please accept or reject the following statement:

    I accept the Church and Basketball browser business workflow demonstrated at tested head e6bc24b6a0df4b585f3ed797e90ec22435619872 and merged main 924fc0351166bebb9870fed0e44b737ff7234bb5 as the current scheduling milestone, subject to the named limitations below. This is not production, provider, physical-service/game, safeguarding, medical, league, or store acceptance.

    Named current product limitations:

    1. Billing and paid SMS remain disabled; external email/SMS delivery is not certified by local mail capture.
    2. The app schedules people but does not prove attendance, safeguarding/skill approval, medical or league eligibility, venue/opponent arrangements, tactical substitutions, or playing time.
    3. Team membership is not a proven solver eligibility boundary; shared-player multi-team operation requires separate acceptance.
    4. Venue travel, family grouping, tournament policy, and automated room/venue collision rules are not provided by these playbooks.
    5. Only one solution per organization is published at a time; a full remaining horizon must be regenerated after cancellation or week-seven rollover, and legacy solutions without solve-scope metadata require regeneration.
    6. Third-party calendar-client polling/rendering and real external inbox delivery require separate manual/provider evidence.
    7. Native physical-device, signed-store, staging, load, operator alert, backup-retention, rollback, and production release acceptance remain in P2: Regenerate the mobile API client and validate native release #191, 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, P2: Run production release acceptance after business flows are accepted #271, and P2: Reconcile platform assurances with later release evidence #284.

    Reply with acceptance of that statement, or name the rejected workflow/limitation and expected behavior. I will not infer owner acceptance from green tests or from a general instruction to continue.

  25. tomqwu commented on Sep 15, 2026

    @tomqwu
    OwnerAuthor

    Latest-main regression receipt

    The complete business-flow suite remains green after the tenant-safe email-event merge.

    • PR Harden tenant-scoped SendGrid delivery events #337 tested head beea983de9eccadb3be5091d5308de7821596eae, merged main cb77a9fd295880359055e8aecc96bbb9d868c19e.
    • make test-all: 2,006 passed / 21 skipped / 0 failed / 0 errors.
    • All 73 Playwright cases passed, including church and basketball every-role availability, exact-qualified cover, eligibility and requirement changes, two-org isolation, complete six-week browser workflows, week-seven rollover, calendars, and local mail/recovery at 360 px and 1440 px.
    • Report: test-artifacts/local-validation/20260915T202718.968598Z-83207-b47448a0/report.json, with exact source SHA and tracked_tree_clean=true.

    This is updated automated evidence only. The existing owner-acceptance request and named limitation list remain the final unchecked criterion; I am not converting a general continue/finish instruction into business sign-off.

  26. tomqwu commented on Sep 15, 2026

    @tomqwu
    OwnerAuthor

    Updated owner acceptance decision for current main

    The earlier acceptance request remains substantively correct, but its revision has been superseded by later locally verified merges. Please accept or reject this current statement:

    I accept the Church and Basketball browser business workflow demonstrated by exact tested PR head beea983de9eccadb3be5091d5308de7821596eae and merged main cb77a9fd295880359055e8aecc96bbb9d868c19e as the current scheduling milestone, subject to the seven named product limitations in the prior acceptance request. This is not production, provider, physical-service/game, safeguarding, medical, league, or store acceptance.

    Current evidence: make test-all 2,006 passed / 21 skipped / 0 failures or errors, including all 73 Playwright church/basketball mobile and desktop cases. The prior seven limitations remain unchanged.

    Reply with acceptance of this statement, or name the rejected workflow/limitation and expected behavior. General continue/finish instructions are not interpreted as owner business sign-off.

  27. tomqwu commented on Sep 15, 2026

    @tomqwu
    OwnerAuthor

    Owner acceptance receipt

    On 2026-09-15, the repository owner explicitly answered yes to the current acceptance request.

    Accepted milestone:

    • exact tested PR head: beea983de9eccadb3be5091d5308de7821596eae;
    • merged main: cb77a9fd295880359055e8aecc96bbb9d868c19e;
    • make test-all: 2,006 passed / 21 skipped / 0 failures or errors, including all 73 Playwright church/basketball cases at 360 px and 1440 px;
    • the seven product limitations listed in the prior acceptance request remain accepted and explicit.

    This closes the local Church/Basketball scheduling milestone only. It does not authorize production deployment, external providers, physical church/game operation, safeguarding or medical/league decisions, native signing/store submission, pilot launch, or general availability. Those remain separately gated in #191, #265, #267, #268, #270, #271, and #284.

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: business-flowCurrent Church/Basketball business-flow work; execute only the active slice in each issue.tests

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions