diff --git a/.planning/README.md b/.planning/README.md new file mode 100644 index 0000000..e6bb1c9 --- /dev/null +++ b/.planning/README.md @@ -0,0 +1,90 @@ +# Planning memory + +This directory preserves the reasoning behind Medora decisions and discoveries across conversations. GitHub Issues track work; these records preserve the context and evidence. PR descriptions and chat history are pointers, not substitutes for the records. + +## Layout and naming + +```text +.planning/ + README.md + templates/ + session.md + decision.md + follow-up.md + decisions/ + / + session.md + D000-.md + D001-.md + follow-ups/ + / + follow-up.md + +``` + +- `DATETIME` is the creation time in UTC, formatted `YYYYMMDDTHHMMSSZ`. Metadata timestamps use ISO 8601 UTC (`YYYY-MM-DDTHH:MM:SSZ`). Record time is not an inferred time of the original conversation. +- `ISSUE-ID` is the actual GitHub issue number, without `#`; store the repository and full issue URL in metadata. Reuse the same folder when continuing a session. A separately scoped session gets a new timestamped folder even if it shares an issue. +- Use lowercase hyphenated title slugs. Preserve directory names and decision IDs after creation; change the display title in metadata. If a creation-time collision occurs, use the next actual creation timestamp, never overwrite another record. +- If GitHub is unavailable, save under `` with a null issue and an explicit blocker. Once an issue exists, rename to the required issue-number form and repair references. Do not invent an issue ID or lose answers while waiting for GitHub. +- Decision IDs are sequential within a session (`D001`, `D002`, etc.); a full reference includes the session folder. `D000` may capture explicit user constraints supplied before the interview. One decision file covers one question; clarification exchanges stay with that decision. +- Cross-record metadata paths are relative to the repository root. Markdown links are relative to their containing file. Use real paths/URLs, `null`, or empty lists; do not invent evidence. +- Templates define required fields and sections. Mark unknown values `null`/`unknown`, and explain genuinely inapplicable sections. Extend records when necessary without silently changing field meanings; increment `schema_version` for incompatible schema changes. + +## Grilling workflow + +1. Read the product vision, the session index if resuming, relevant predecessor decisions, and related follow-ups. Create or reuse the tracking issue and session folder. Record the topic, constraints, participants, origin, and scope before the first round. +2. Build a decision tree. Ask only questions whose prerequisites are settled; record prerequisite links and the unresolved branches in `session.md`. Recommendations and alternatives belong beside the exact question, not in the confirmed-decision field. +3. Save each answer before asking the next round. Quote the user's words separately from the assistant's interpretation. Record a message/turn description if no conversation URL or message ID is available. For partial answers, retain unresolved subquestions; never substitute the recommendation for an omitted answer. +4. An explicit, unambiguous user choice can confirm that decision. When the user explicitly delegates a choice, record the delegation source, the assistant-selected outcome, and its rationale without attributing the details to the user. If the interpretation introduces commitments the user did not state, use `needs-clarification` and ask. Silence, a timeout, and an assistant recommendation never confirm a decision. +5. Maintain the session's decision table, dependency tree, current question frontier, deferred branches, and linked follow-ups. A deliberately deferred question must name its reason, blocking prerequisite or revisit trigger, and follow-up when it represents future work. +6. Preserve history when an answer changes. Append the new exchange, record what changed and why, and identify downstream decisions needing reconsideration. A replacement decision links `supersedes`; the older record links `superseded_by`. Keep old replies intact rather than rewriting them to fit the latest outcome. +7. Before ending a round, persist records and report anything not yet saved. Follow the repository's branch/PR workflow for publication. Keep an ongoing interview's PR in draft and its issue open; saving records does not imply the session is complete. +8. When all in-scope branches are resolved or explicitly deferred, present the shared understanding and request explicit session confirmation. Store that confirmation before implementing the resulting design. Logging rules already requested by the user may be written during the interview. + +Session statuses: `active`, `awaiting-confirmation`, `confirmed`, `paused`, `superseded`. Decision statuses: `unanswered`, `needs-clarification`, `confirmed`, `deferred`, `superseded`. A reopened decision returns to `needs-clarification` with its earlier answer retained in history. + +## Follow-up workflow + +- Capture an unrelated idea, bug, risk, question, or deferred task as soon as it is recognized. Record why it arose, when it was observed, where it was encountered, the current task, relevant evidence, analysis, affected product capabilities or code components, and why it is outside the current scope. +- Search existing follow-ups before creating another. Add new evidence to an existing record for the same concern. Distinct duplicates link to the canonical record; do not discard their provenance. +- Separate observed facts, user reports, hypotheses, and unknowns. Include reproduction steps for bugs when available; use explicit `not applicable` for other kinds. Do not invent a diagnosis or priority. +- `kind` is one of `feat`, `bug`, `docs`, `research`, `question`, `security`, `perf`, `refactor`, `test`, `ci`, `build`, `chore`. Record severity separately from delivery priority; an unassessed item has null values. +- Status progresses from `captured` to `triaged`, `scheduled`, `in-progress`, then `resolved`; `dismissed` and `duplicate` are alternative outcomes. Record an owner, next action, dependencies, and revisit trigger as they become known. Capture alone neither expands the current task nor authorizes implementation. +- Before related work, read matching open records and check whether their assumptions still hold. When promoting one to a GitHub issue, link both directions and keep the original context here. Resolve only with outcome/verification evidence; dismissal needs a reason, and duplication needs a canonical link. +- Keep each follow-up folder's `follow-up.md` as its canonical record. Update the index below when creating, scheduling, superseding, or resolving records. + +## Confidentiality and sources + +Use synthetic patient examples and avoid private practice details or credentials in this public repository. Preserve user replies verbatim when safe; if redaction is necessary, mark the redaction and reason explicitly and never claim the stored text is an unaltered transcript. Link restricted evidence instead of copying sensitive content. Record only relevant conversation excerpts. + +Confirmed planning decisions inform product documents and implementation issues; those should link back to the originating records. A future architecture ADR records the architectural decision and links to relevant planning history. Do not silently replace an existing product constraint or ADR with a new interpretation. + +## Feature register + +[Product feature register](feature-register.md) preserves the full capability vision and separates confirmed first-increment scope from unsequenced work. + +## Schemas + +- [Session schema](templates/session.md): purpose, scope, issue, origin, decision tree, round index, unresolved branches, follow-ups, and final confirmation. +- [Decision schema](templates/decision.md): context, predecessors, exact question, recommendations, raw replies, interpretation, outcome, consequences, evidence, and history. +- [Follow-up schema](templates/follow-up.md): why/when/where, analysis, affected components, kind, impact, next action, dependencies, and closure evidence. + +## Sessions + +| Session | Scope | Status | +| --- | --- | --- | +| [20261015T085738Z-3](decisions/20261015T085738Z-3/session.md) | Product functionality and initial scope; no technical stack | confirmed | + +## Follow-ups + +| Follow-up | Kind | Status | Revisit trigger | +| --- | --- | --- | --- | +| [Select i18n/localization libraries](follow-ups/20261015T102802Z-select-internationalization-and-localization-libraries/follow-up.md) | build | captured | Technical stack planning after language requirements | +| [AI-generated additional UI translations](follow-ups/20261015T110819Z-ai-generated-additional-ui-translations/follow-up.md) | feat | captured | Expansion beyond the initial four languages | +| [Choose beta operating countries](follow-ups/20261015T121349Z-choose-beta-operating-countries/follow-up.md) | question | captured | Before beta eligibility/local operating rules | +| [Validate WhatsApp linked-line onboarding](follow-ups/20261015T142428Z-validate-whatsapp-linked-line-onboarding/follow-up.md) | research | captured | Technical integration planning before promising connection modes | +| [Define detailed booking and rescheduling policies](follow-ups/20261015T155426Z-define-detailed-booking-policies/follow-up.md) | question | captured | Before implementing the affected scheduling policies or activating them for a practice | +| [Define identity, permissions and sharing access rules](follow-ups/20261015T155426Z-define-identity-permissions-and-sharing/follow-up.md) | question | captured | Before enabling affected record access, membership administration, sharing or booking changes | +| [Define handoff, group and notification workflows](follow-ups/20261015T155426Z-define-handoff-and-notification-workflows/follow-up.md) | question | captured | Before implementing or enabling the corresponding handoff, group or delivery-failure flows | +| [Define profile, intake and correction details](follow-ups/20261015T155426Z-define-profile-fields-and-intake-details/follow-up.md) | question | captured | Before implementing affected profile/intake behavior or collecting real patient intake | +| [Define beta validation and public-release criteria](follow-ups/20261015T155426Z-define-beta-validation-and-release-gates/follow-up.md) | question | captured | Before inviting real beta practices or claiming readiness for broader advertising | diff --git a/.planning/decisions/20261015T085738Z-3/D000-planning-memory-and-scope.md b/.planning/decisions/20261015T085738Z-3/D000-planning-memory-and-scope.md new file mode 100644 index 0000000..66c08b6 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D000-planning-memory-and-scope.md @@ -0,0 +1,77 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D000", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "User-directed session scope and durable planning records", + "status": "confirmed", + "round": 0, + "created_at": "2026-10-15T08:57:38Z", + "updated_at": "2026-10-15T08:57:38Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Agent instructions", + "Planning memory", + "Product discovery" + ], + "follow_ups": [], + "sources": [ + "User message invoking grill-me in the current conversation" + ] +} +--- + +# Context — why ask this? + +The user initiated product discovery and explicitly requested durable reasoning records to prevent decisions and unrelated discoveries from being lost in chat or PRs. This is a direct instruction, not a question asked by the assistant. + +## Predecessor decisions + +None. The existing product vision supplies the product context. + +## Question + +Not applicable: the user supplied the instruction before the first interview round. + +## Recommendation and alternatives + +The assistant proposes versioned Markdown templates, one session index and one file per decision, plus separate follow-up records. Field names, UTC formatting, statuses, and file organization are implementation choices for the requested schema; they are editable and were not separately dictated by the user. + +## User reply — original words + +Source: current conversation, user message invoking `$grill-me`; no message timestamp or URL was provided. + +> $grill-me lets do some digging about the project functionalities, ideas etc ... (no technical stack for now) also, id like you for each grilling session we create from now on, store the decisions under .planning/decisions// each decision shall cover the context (why it was asked?) the predecessor decisions, the question, the user reply, the intepretation, extra notes .... save this into your instructions! same apply for follow-ups, occutionally, we will some follow ups that are unrelated to current task at hand, instead of adding it only to PR or somewhere where its hard to remember, we log it into .planning/follow-ups/ it shall has good context like: why, when, where, analysis, affected components, kind: feat / bug / ... etc .... (draft a complete schema) + +## Interpretation + +Record future Medora grilling sessions in the requested session folders, including exact exchanges and dependency context. Record unrelated follow-ups independently with enough context to act later. Persist the rules in repository agent instructions. Explore product functionality now; defer technical stack selection. + +## Decision and rationale + +The logging requirement and current scope are confirmed by the direct user instruction. The user wants discoverable context beyond PR descriptions. The schema is a concrete draft implementing that request; individual product questions remain unanswered. Null answer/confirmation timestamps indicate that the original message time was not available; created_at records when this evidence was saved. + +## Consequences and affected components + +AGENTS.md points future sessions to the planning lifecycle and templates. Every interview round must preserve replies before continuing. Incidental ideas remain discoverable without silently expanding the active task. + +## Assumptions, evidence, and open questions + +Persistence is repository-scoped. Global agent settings are not modified. The final product design has not been confirmed. + +## Extra notes and follow-ups + +No unrelated follow-up has been identified yet. No application work is authorized by merely recording an idea. + +## History + +- 2026-10-15T08:57:38Z — Assistant recorded the explicit user instruction and distinguished it from proposed schema details. diff --git a/.planning/decisions/20261015T085738Z-3/D001-first-practice.md b/.planning/decisions/20261015T085738Z-3/D001-first-practice.md new file mode 100644 index 0000000..89f2baf --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D001-first-practice.md @@ -0,0 +1,126 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D001", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "First practice", + "status": "confirmed", + "round": 1, + "created_at": "2026-10-15T08:57:38Z", + "updated_at": "2026-10-15T15:44:38Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Doctor experience", + "Staff workflows" + ], + "follow_ups": [], + "sources": [ + "docs/product-vision.md", + "Current conversation: first-round user answers; later user message completes Q4" + ], + "reply_recorded_at": "2026-10-15T12:13:49Z", + "rounds": [ + 1, + 2, + 3 + ], + "amended_by": [ + ".planning/decisions/20261015T085738Z-3/D034-practice-configuration-ownership.md" + ] +} +--- + +# Context — why ask this? + +The intended audience includes several operating models; the initial daily user and division of work are unsettled. + +## Predecessor decisions + +Root product question; no predecessor product decision is required. The supplied product vision and session scope remain constraints. + +## Question + +For the first version, are we serving a doctor working alone, a doctor with a receptionist, or a small multi-doctor clinic? Who would use Medora every day? + +### Round 2 clarification — Q5 — Shared practice + +Do doctors and receptionists belong to a shared practice, with receptionists managing several doctors, or does each doctor have a separate team? Should both arrangements be supported? + +### Round 3 clarification — Q9 — Long-term practice model + +Shall we use a practice/clinic organization as the home for one or more doctors and receptionists, with optional locations and people able to work across practices under separate permissions? + +## Recommendation and alternatives + +Start with one practitioner, with or without a receptionist, and name one primary daily operator. Expand to shared clinic coordination after that workflow is understood. + +This is an assistant recommendation, not a user decision. Alternatives remain open until the user replies. + +Round 2 recommendation: Use a practice as the working group: one or more doctors, with receptionists assigned to the doctors they support. Treat a solo practice as the one-doctor case. + +No reply to the round 2 clarification has been received. + +Round 3 recommendation: Yes. This supports solo doctors and growing clinics without making patient records automatically visible across independent practices. + +No reply to round 3 has been received. + +## User reply — original words + +Recorded 2026-10-15T10:28:02Z. Source: current conversation; original message timestamps were not supplied. + +> q1. its a doctor(s) and receptionist(s) (its three roles: Doctor, Receptionist, Patient) + +Round 2 reply, recorded 2026-10-15T11:08:19Z; original message timestamp unavailable: + +> Q5: think about far future, what will be the most natural choice here + +Round 3 reply, recorded 2026-10-15T12:13:49Z; original message timestamp unavailable: + +> q9: ok + +## Interpretation + +The user accepts the previously described practice/clinic organization model. It supports one or more doctors/receptionists, optional locations, and separate memberships for people working across practices. Access remains practice-scoped; this is not permission to expose records across practices. + +## Decision and rationale + +Confirmed: practice/clinic organization as the long-term operating model, with the solo practice as the smallest case. Multiple-location delivery timing and granular staff permissions remain to be decided. + +Current role-set amendment: [D034](D034-practice-configuration-ownership.md) adds the user-requested explicit practice Owner/Admin account. Doctor, Receptionist and Patient remain the operational roles; the earlier three-role-only framing is no longer the complete role model. The accepted practice/clinic grouping remains valid. + +## Consequences and affected components + +Practice membership and role-aware staff workflows can now be explored. A person may work across practices without automatic cross-practice data access. Locations are supported by the long-term model; the first-release location depth remains open. + +## Assumptions, evidence, and open questions + +Practice ownership/configuration capabilities, staff assignment scope, shared calendars, staff chat visibility, and first-increment location support remain open. The three user roles are retained; no additional administrator role has been introduced. + +## Extra notes and follow-ups + +Technical stack selection is outside this session. No follow-up captured for this unanswered question. + +## History + +- 2026-10-15T08:57:38Z — Assistant prepared the first-round question; user response is pending. + +- 2026-10-15T10:28:02Z — Assistant saved the actual reply and its interpretation; status is needs-clarification. Original recommendations remain historical proposals. + +- 2026-10-15T11:08:19Z — Recorded round 2 answer; status needs-clarification. + - Previous interpretation: The user explicitly establishes three roles: Doctor, Receptionist, Patient, and includes doctors and receptionists rather than accepting a doctor-only starting point. The plural forms allow multiple people; they do not establish whether staff share one practice, serve assigned doctors, or operate independently. A single primary daily operator was not selected. + - Previous decision summary: Confirmed portion: the product has Doctor, Receptionist, and Patient roles. Practice grouping and how receptionists support doctors remain open; the assistant's single-practitioner recommendation was not accepted as a constraint. The user did not supply a further rationale; none is attributed to them. + +- 2026-10-15T12:13:49Z — Saved round 3 reply; status confirmed. + - Prior interpretation: The user requests a long-term product recommendation instead of choosing a practice grouping. The three roles remain confirmed; the assistant must not report its recommended organization model as user-approved. + - Prior decision summary: The assistant recommends a practice/clinic organization with one or more locations, doctors, and receptionists. A person can work with multiple practices through separate memberships; record access stays scoped to the practice. A solo practice is the smallest instance. Exact location depth and cross-practice sharing are not first-release commitments. + +- 2026-10-15T15:44:38Z — Linked the partial role-set amendment from Q42; preserved original replies and the organization decision. diff --git a/.planning/decisions/20261015T085738Z-3/D002-anchor-problem.md b/.planning/decisions/20261015T085738Z-3/D002-anchor-problem.md new file mode 100644 index 0000000..b07ff65 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D002-anchor-problem.md @@ -0,0 +1,102 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D002", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Main problem", + "status": "confirmed", + "round": 1, + "created_at": "2026-10-15T08:57:38Z", + "updated_at": "2026-10-15T11:08:19Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Appointment coordination", + "Product scope" + ], + "follow_ups": [], + "sources": [ + "docs/product-vision.md", + "Current conversation: first-round user answers; later user message completes Q4" + ], + "reply_recorded_at": "2026-10-15T11:08:19Z", + "rounds": [ + 1, + 2 + ] +} +--- + +# Context — why ask this? + +The vision lists many benefits but does not identify the primary reason a practice would adopt Medora. + +## Predecessor decisions + +Root product question; no predecessor product decision is required. The supplied product vision and session scope remain constraints. + +## Question + +Which problem must Medora solve first to make someone change their current habits: interruptions from appointment requests, rescheduling back-and-forth, missed appointments, or missing patient information? Choose one; give a concrete example if you have one. + +### Round 2 clarification — Q6 — Meaning of “all” + +Does “all” mean the first public version must cover booking, rescheduling, reminders, and basic patient intake together? Or are these all product goals that can arrive in successive releases? + +## Recommendation and alternatives + +Make routine appointment coordination the first promise: turn a request into a confirmed appointment with minimal staff effort. Use the other benefits to support that promise. + +This is an assistant recommendation, not a user decision. Alternatives remain open until the user replies. + +Round 2 recommendation: Launch with a basic end-to-end version of all four, while developing them incrementally. Leave advanced optimization and richer patient summaries for later. + +No reply to the round 2 clarification has been received. + +## User reply — original words + +Recorded 2026-10-15T10:28:02Z. Source: current conversation; original message timestamps were not supplied. + +> Q2: All + +Round 2 reply, recorded 2026-10-15T11:08:19Z; original message timestamp unavailable: + +> Q6: ALl must be registred, but we gradually add neww features, we will start with the basic booking and profiling + +## Interpretation + +Keep the full feature vision recorded and deliver it incrementally. The starting increment is basic booking and patient profiling. The user did not require reminders, full rescheduling coordination, or every planned feature to ship together. The detailed meaning of basic profiling still needs clarification. + +## Decision and rationale + +Confirmed: preserve all features in the register, add features gradually, and begin with basic booking and profiling. This supersedes the assistant recommendation to launch all four workflows together; no rationale beyond the stated incremental approach is attributed to the user. + +## Consequences and affected components + +The initial feature boundary is confirmed at the capability level. A feature register preserves the wider vision without promising delivery dates. Booking entry, confirmation policy, profile content, and later-feature sequencing remain open. + +## Assumptions, evidence, and open questions + +Detailed booking entry points and profile fields remain open. No reminders/rescheduling delivery date is promised. The wider feature vision remains recorded in the product vision and feature register. + +## Extra notes and follow-ups + +The [feature register](../../feature-register.md) preserves all vision features and distinguishes the first increment from unsequenced work. No additional feature has been silently removed. + +## History + +- 2026-10-15T08:57:38Z — Assistant prepared the first-round question; user response is pending. + +- 2026-10-15T10:28:02Z — Assistant saved the actual reply and its interpretation; status is needs-clarification. Original recommendations remain historical proposals. + +- 2026-10-15T11:08:19Z — Recorded round 2 answer; status confirmed. + - Previous interpretation: All four named problems matter to the user: booking interruptions, rescheduling exchanges, missed appointments, and missing patient information. This does not establish equal priority, release depth, or that every advanced feature must ship in the first version. + - Previous decision summary: Confirmed portion: preserve all four benefits in the product scope. Release sequencing and the minimum depth of each remain unresolved. The user did not supply a further rationale; none is attributed to them. diff --git a/.planning/decisions/20261015T085738Z-3/D003-pilot-market.md b/.planning/decisions/20261015T085738Z-3/D003-pilot-market.md new file mode 100644 index 0000000..b18ec57 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D003-pilot-market.md @@ -0,0 +1,127 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D003", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "First pilot market", + "status": "deferred", + "round": 1, + "created_at": "2026-10-15T08:57:38Z", + "updated_at": "2026-10-15T12:13:49Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Patient communication", + "Practice onboarding" + ], + "follow_ups": [ + ".planning/follow-ups/20261015T102802Z-select-internationalization-and-localization-libraries/follow-up.md", + ".planning/follow-ups/20261015T110819Z-ai-generated-additional-ui-translations/follow-up.md", + ".planning/follow-ups/20261015T121349Z-choose-beta-operating-countries/follow-up.md" + ], + "sources": [ + "docs/product-vision.md", + "Current conversation: first-round user answers; later user message completes Q4" + ], + "reply_recorded_at": "2026-10-15T12:13:49Z", + "rounds": [ + 1, + 2, + 3 + ] +} +--- + +# Context — why ask this? + +International ambition does not specify the initial operating environment or language expectations. No market is inferred from the development timezone. + +## Predecessor decisions + +Root product question; no predecessor product decision is required. The supplied product vision and session scope remain constraints. + +## Question + +Which country should the first real pilot serve, and which languages must patients and staff be able to use from day one? + +### Round 2 clarification — Q7 — Initial audience and languages + +English code and a localized UI are recorded. Which countries and actual UI languages should the first release support? If that is undecided, say so and we will keep it explicitly open. + +### Round 3 clarification — Q12 — Beta geography + +Which country or countries will the beta practices operate in, or should we leave that undecided until beta recruitment? + +## Recommendation and alternatives + +Choose one initial market and the languages its actual users need. Keep international expansion as the longer-term direction. + +This is an assistant recommendation, not a user decision. Alternatives remain open until the user replies. + +Round 2 recommendation: Choose a defined initial audience and supported language list, even if Medora is designed to expand internationally. + +No reply to the round 2 clarification has been received. + +Round 3 recommendation: Name the first beta market before defining country-specific operating rules. We can continue the general product design while that choice is open. + +No reply to round 3 has been received. + +## User reply — original words + +Recorded 2026-10-15T10:28:02Z. Source: current conversation; original message timestamps were not supplied. + +> Q3: CODE is ENG, UI is translated using i18n libraries and localisation libraries .. + +Round 2 reply, recorded 2026-10-15T11:08:19Z; original message timestamp unavailable: + +> Q7: we will start with ENGLISH, FRENCH, ARABIC, SPANISH (other languages can be auto generated using AI models) + +Round 3 reply, recorded 2026-10-15T12:13:49Z; original message timestamp unavailable: + +> q12: undecided + +## Interpretation + +Beta geography is explicitly undecided. Existing English/French/Arabic/Spanish UI commitments remain valid; languages do not establish operating countries. Keep country-specific decisions open and capture a follow-up for beta planning. + +## Decision and rationale + +Confirmed language choices are retained. The geography portion is deferred with no country inferred. Revisit before defining beta recruitment eligibility and country-specific operating rules. + +## Consequences and affected components + +Initial language list is known; Arabic requires a UI suitable for right-to-left reading. Locale variants, patient-facing conversation languages, translation quality checks, and geographic launch scope remain open. No library or model is selected. + +## Assumptions, evidence, and open questions + +The beta market is deliberately undecided. Locale-specific operational decisions remain unresolved until the follow-up is revisited. UI language list is confirmed; regional variants, AI conversation coverage, and generated-translation publication remain open. + +## Extra notes and follow-ups + +[Library selection follow-up](../../follow-ups/20261015T102802Z-select-internationalization-and-localization-libraries/follow-up.md) captures the technical requirement for a later session. No library choice is being made now. + +[AI-generated additional translations](../../follow-ups/20261015T110819Z-ai-generated-additional-ui-translations/follow-up.md) records the new extension idea and its unresolved review/publication behavior. + +[Beta geography follow-up](../../follow-ups/20261015T121349Z-choose-beta-operating-countries/follow-up.md) holds the deferred country choice and revisit trigger. + +## History + +- 2026-10-15T08:57:38Z — Assistant prepared the first-round question; user response is pending. + +- 2026-10-15T10:28:02Z — Assistant saved the actual reply and its interpretation; status is needs-clarification. Original recommendations remain historical proposals. + +- 2026-10-15T11:08:19Z — Recorded round 2 answer; status needs-clarification. + - Previous interpretation: Code should be in English. The UI should support translation and localization through suitable libraries. This is a product/engineering constraint, not a selection of a particular library, application stack, initial market, or actual supported languages. UI translation does not by itself specify AI conversation languages. + - Previous decision summary: Confirmed portion: English code and a translated/localized UI. Country coverage, the first language list, and AI conversation language support remain unresolved. Specific library selection is deferred outside this product interview. The user did not supply a further rationale; none is attributed to them. + +- 2026-10-15T12:13:49Z — Saved round 3 reply; status deferred. + - Prior interpretation: The first UI languages are English, French, Arabic, and Spanish. The user also wants the ability to generate additional translations using AI. Code remains English. This does not select deployment countries, regional language variants, AI conversation coverage, a model/provider, or an automatic publication/review policy. + - Prior decision summary: Confirmed portions: English code, localized UI, and initial support for English, French, Arabic, Spanish. AI-generated additional translations are recorded as an extension capability; review and publication behavior are unresolved. First beta country/countries remain unspecified. diff --git a/.planning/decisions/20261015T085738Z-3/D004-validation-access.md b/.planning/decisions/20261015T085738Z-3/D004-validation-access.md new file mode 100644 index 0000000..2649e86 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D004-validation-access.md @@ -0,0 +1,88 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D004", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Access to real users", + "status": "confirmed", + "round": 1, + "created_at": "2026-10-15T08:57:38Z", + "updated_at": "2026-10-15T10:28:02Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Product validation", + "Pilot planning" + ], + "follow_ups": [], + "sources": [ + "docs/product-vision.md", + "Current conversation: first-round user answers; later user message completes Q4" + ], + "reply_recorded_at": "2026-10-15T10:28:02Z" +} +--- + +# Context — why ask this? + +A proposed audience does not establish access to evidence or a pilot partner. This distinguishes observed needs from assumptions. + +## Predecessor decisions + +Root product question; no predecessor product decision is required. The supplied product vision and session scope remain constraints. + +## Question + +Do you already have doctors or receptionists you can interview or observe, and is anyone willing to try an early version? Describe their roles and your access; names or private practice details are unnecessary. + +## Recommendation and alternatives + +Anchor the discovery in one reachable practice. If none is available, record our product choices as hypotheses to validate. + +This is an assistant recommendation, not a user decision. Alternatives remain open until the user replies. + +## User reply — original words + +Recorded 2026-10-15T10:28:02Z. Source: current conversation; original message timestamps were not supplied. + +Earlier incomplete reply, preserved: + +> Q4: Not yet, I will + +Completed reply in the following user message: + +> Q4: Not yet, I will advertise my product when its live and functionning; + +## Interpretation + +The user currently has no practitioners available for interviews or an early pilot and intends to advertise after the product is live and functioning. The latest reply completes the interrupted earlier answer. It does not say that a limited early release is forbidden or that workflows have already been validated. + +## Decision and rationale + +No current practitioner access is established; the user plans to advertise once the product is live and functioning. This describes current access and intended timing, not proof of demand or a final release-validation policy. The user did not supply a further rationale; none is attributed to them. + +## Consequences and affected components + +Treat product workflow assumptions as unvalidated. Ask what release approach should establish readiness before broad advertising; do not recruit or contact anyone automatically. + +## Assumptions, evidence, and open questions + +What “live and functioning” requires, whether a limited early release is acceptable, and how feedback will be gathered remain open. D005/Q8 covers release approach. The user reply is the source; no practitioner evidence has been gathered. + +## Extra notes and follow-ups + +Technical stack selection is outside this session. No follow-up captured for this unanswered question. + +## History + +- 2026-10-15T08:57:38Z — Assistant prepared the first-round question; user response is pending. + +- 2026-10-15T10:28:02Z — Assistant saved the actual reply and its interpretation; status is confirmed. Original recommendations remain historical proposals. diff --git a/.planning/decisions/20261015T085738Z-3/D005-release-readiness.md b/.planning/decisions/20261015T085738Z-3/D005-release-readiness.md new file mode 100644 index 0000000..b59a822 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D005-release-readiness.md @@ -0,0 +1,90 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D005", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Early release and readiness to advertise", + "status": "confirmed", + "round": 2, + "created_at": "2026-10-15T10:28:02Z", + "updated_at": "2026-10-15T11:08:19Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D004-validation-access.md" + ], + "related_decisions": [ + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md" + ], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Release scope", + "Product validation", + "Practice onboarding" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D004-validation-access.md" + ], + "reply_recorded_at": "2026-10-15T11:08:19Z" +} +--- + +# Context — why ask this? + +The user plans to advertise once Medora is live and functioning, without current access to practitioner validation. Release readiness and the intended first audience are still undefined. + +## Predecessor decisions + +[D004](D004-validation-access.md) establishes no current practitioner access and intended advertising after a functioning release. This question depends only on that confirmed intent, not on a chosen country or technical stack. + +## Question + +Q8 — Ready to advertise: Once Medora is working, would you invite a few practices into a limited early release before broad advertising, or should the first release be immediately open to everyone? + +## Recommendation and alternatives + +Use a limited early release to validate complete doctor, receptionist, and patient workflows, then advertise more broadly. No recruitment or outreach happens without your instruction. + +Alternative: open public signup immediately. The unresolved tradeoff is whether real workflow feedback arrives before or during broad adoption. The user has now accepted early access for beta users; the detailed rollout remains to be defined. + +## User reply — original words + + + +Round 2 reply, recorded 2026-10-15T11:08:19Z; original message timestamp unavailable: + +> Q8: Yeah beta users get early access + +## Interpretation + +The user accepts early access for beta users before the broader release. They have not named recruited participants, a beta size, duration, paid/free policy, invitation mechanism, or exit criteria. + +## Decision and rationale + +Confirmed: beta users get early access. The earlier intent to advertise a functioning product is retained; this answer adds an early-access stage rather than proving practitioner validation has occurred. + +## Consequences and affected components + +Beta scope and readiness criteria can now be explored after core booking/profile behavior is specified. No outreach, recruitment, or deployment is authorized by recording this choice. + +## Assumptions, evidence, and open questions + +Early access is accepted. Beta size, timing, recruitment, success measures, pricing, and public-release gates are not defined. There are still no confirmed practitioner contacts. + +## Extra notes and follow-ups + +The existing no-stack constraint remains. No independent follow-up is needed for this in-scope product question. + +## History + +- 2026-10-15T10:28:02Z — Assistant prepared Q8 after recording the completed Q4 reply. + +- 2026-10-15T11:08:19Z — Recorded round 2 answer; status confirmed. + - Previous interpretation: Pending. + - Previous decision summary: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D006-booking-entry.md b/.planning/decisions/20261015T085738Z-3/D006-booking-entry.md new file mode 100644 index 0000000..61391aa --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D006-booking-entry.md @@ -0,0 +1,111 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D006", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "First booking experience", + "status": "confirmed", + "round": 3, + "created_at": "2026-10-15T11:08:19Z", + "updated_at": "2026-10-15T13:46:49Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Appointment requests", + "Receptionist scheduling", + "Patient experience" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T13:46:49Z", + "rounds": [ + 3, + 4 + ] +} +--- + +# Context — why ask this? + +The user confirmed basic booking as the starting capability, but the entry journey is unspecified. The channel affects identity, availability presentation, and required confirmations. + +## Predecessor decisions + +[D002](D002-anchor-problem.md) confirms basic booking and profiling as the first increment. This question does not require an answer to the organization-model recommendation. + +## Question + +Q10 — First booking experience: For the first version, should patients book directly through a practice link, should receptionists enter bookings, or do you need both? Are messaging and telephone assistants required immediately? + +### Round 4 clarification — Q13 — Booking inside messaging + +For the first release, must a patient complete the entire booking conversation inside WhatsApp, or is receiving a link to a booking page sufficient? + +## Recommendation and alternatives + +Start with patient self-booking through a practice link and receptionist-created bookings. Record messaging and telephone automation for later unless they are essential to your first users. + +The alternatives in the question remain available. This is a recommendation, not an accepted scope decision. + +Round 4 recommendation: Make WhatsApp the first complete patient conversation channel if messaging is central to Medora. Add other messaging apps gradually; keep a booking link as an optional fallback. + +The round 4 reply is recorded below. Earlier recommendations are historical proposals; the current decision is authoritative. + +## User reply — original words + + + +Round 3 reply, recorded 2026-10-15T12:13:49Z; original message timestamp unavailable: + +> q10: yes both, patient will likely use channels such as whatsapp and other messaging apps to book an appointment , staff on the otherside uses the chat interface ( a private realm to mgmt) + +Round 4 reply, recorded 2026-10-15T13:46:49Z; original message timestamp unavailable: + +> q13: idk how are you interpretting the project, but the overaall goal is to make booking an easy task for patients, why would they need a UI for such thing (there are already solutions like those!) they do regular chitchat with the agent and the whatsapp agent do the booking for them, and they can ask about there approintements and other staff throught the whatsapp, thets the core idea! + +## Interpretation + +The user corrects the assistant: the core patient experience is natural conversation with the WhatsApp agent, which performs booking and handles appointment questions directly in chat. Requiring a patient booking UI would defeat that intended experience. WhatsApp is a core initial product channel, not merely a speculative future integration. The phrase other staff is preserved verbatim and not interpreted as access to private staff conversations; additional patient questions remain to be bounded. + +## Decision and rationale + +Confirmed: patients converse naturally with the WhatsApp agent to book and ask about their appointments. No separate patient booking UI is required for this core journey. Staff retain a separate private management chat. The assistant's booking-page-first recommendation is not adopted. + +## Consequences and affected components + +Correct the agent guidance, product vision, and feature register to prevent drifting toward a patient booking form. Availability checks, provisional reservations, appointment inquiries, and outcome notifications must be achievable conversationally. Other messaging channels remain part of the broader vision; their sequence is unspecified. + +## Assumptions, evidence, and open questions + +The scope of additional patient questions, identity verification, supported conversational languages, doctor selection, cancellation/rescheduling details, and human handoff remain unresolved. This confirmation does not imply that a reservation is already a confirmed appointment. + +## Extra notes and follow-ups + +Related questions are continuing within this product session. No unrelated follow-up was introduced by this reply. + +## History + +- 2026-10-15T11:08:19Z — Assistant prepared this question after the initial-capability decision was confirmed. + +- 2026-10-15T12:13:49Z — Saved round 3 reply; status needs-clarification. + - Prior interpretation: Pending. + - Prior decision summary: Pending. + +- 2026-10-15T13:46:49Z — Saved round 4 reply and confirmed the explicit choice. + - Prior interpretation: Both patients and staff can initiate appointment management. The intended patient experience uses messaging channels, with WhatsApp specifically named as likely; staff use a private management chat. This does not confirm a standalone booking-page requirement, a mandatory first-release WhatsApp integration, a list of other apps, shared staff transcripts, or telephone support. + - Prior decision summary: Confirmed portions: patient and staff entry paths; private staff management chat; patient messaging is the intended direction, with WhatsApp a likely channel. Initial channel commitments and whether booking is completed inside messaging remain open. + +- 2026-10-15T13:46:49Z — Assistant acknowledged misunderstanding the central patient experience and corrected the booking-page-first framing. No patient UI fallback is introduced as a requirement. diff --git a/.planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md b/.planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md new file mode 100644 index 0000000..af92c44 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md @@ -0,0 +1,109 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D007", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Meaning of profiling", + "status": "confirmed", + "round": 3, + "created_at": "2026-10-15T11:08:19Z", + "updated_at": "2026-10-15T13:46:49Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Patient profiles", + "Intake", + "Consultation preparation" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T13:46:49Z", + "rounds": [ + 3, + 4 + ] +} +--- + +# Context — why ask this? + +The user confirmed profiling as part of the initial increment. Its boundaries determine what information is collected and whether the product expands into clinical-record management. + +## Predecessor decisions + +[D002](D002-anchor-problem.md) confirms basic booking and profiling as the first increment. This question does not require an answer to the organization-model recommendation. + +## Question + +Q11 — Meaning of profiling: Does basic profiling mean contact details plus the reason for the visit and a short pre-appointment intake, or do you also expect a longitudinal clinical record with diagnoses, prescriptions, and documents? + +### Round 4 clarification — Q15 — A concrete basic profile + +For the first release, shall a profile contain identity/contact details, appointment history, and patient-reported visit reasons with short intake attached to each appointment, while clinician-authored diagnoses, prescriptions, and full medical-record management remain later possibilities? + +## Recommendation and alternatives + +Start with a persistent administrative patient profile and intake linked to each appointment. Keep patient-reported information clearly identified; defer full clinical-record functionality. + +The alternatives in the question remain available. This is a recommendation, not an accepted scope decision. + +Round 4 recommendation: Use that administrative profile plus appointment-specific intake as the starting scope. It gives the doctor preparation context without committing this increment to a complete clinical-record system. + +The round 4 reply is recorded below. Earlier recommendations are historical proposals; the current decision is authoritative. + +## User reply — original words + + + +Round 3 reply, recorded 2026-10-15T12:13:49Z; original message timestamp unavailable: + +> q11: hmm, maybe ? + +Round 4 reply, recorded 2026-10-15T13:46:49Z; original message timestamp unavailable: + +> q15: ok + +## Interpretation + +The user accepts the concrete initial profile proposed in Q15: patient identity/contact details, appointment history, patient-reported visit reasons, and short intake attached to each appointment. Clinician-authored diagnoses, prescriptions, and full medical-record management remain later possibilities rather than initial features. + +## Decision and rationale + +Confirmed: start with an administrative patient profile and appointment-specific preliminary intake, retaining patient-reported attribution. Full clinical-record functionality is outside the initial increment. + +## Consequences and affected components + +The booking conversation can collect minimal identity/contact details and relevant intake, and prepare useful doctor context. Profile lifecycle, exact required fields, skip behavior, access, and conversation-to-profile review remain product questions. + +## Assumptions, evidence, and open questions + +Exact identity/contact fields, optional intake, matching returning patients, who may edit a profile, and patient visibility/correction workflows are not yet chosen. Acceptance of this profile is not approval of medical diagnosis or prescribing. + +## Extra notes and follow-ups + +Related questions are continuing within this product session. No unrelated follow-up was introduced by this reply. + +## History + +- 2026-10-15T11:08:19Z — Assistant prepared this question after the initial-capability decision was confirmed. + +- 2026-10-15T12:13:49Z — Saved round 3 reply; status needs-clarification. + - Prior interpretation: Pending. + - Prior decision summary: Pending. + +- 2026-10-15T13:46:49Z — Saved round 4 reply and confirmed the explicit choice. + - Prior interpretation: The user is uncertain about the proposed profile boundary. No choice between administrative intake and a fuller clinical record has been made. The assistant must explain the proposed first-increment scope concretely and obtain a choice. + - Prior decision summary: No profile-content decision is confirmed. Basic profiling remains part of the first increment, but its content and clinical-record boundary are unresolved. diff --git a/.planning/decisions/20261015T085738Z-3/D008-staff-chat-privacy.md b/.planning/decisions/20261015T085738Z-3/D008-staff-chat-privacy.md new file mode 100644 index 0000000..f066dc1 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D008-staff-chat-privacy.md @@ -0,0 +1,91 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D008", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Staff chat privacy", + "status": "confirmed", + "round": 4, + "created_at": "2026-10-15T12:13:49Z", + "updated_at": "2026-10-15T13:46:49Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Staff assistant", + "Practice collaboration", + "Conversation visibility" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T13:46:49Z" +} +--- + +# Context — why ask this? + +A private management realm excludes patients but does not establish whether staff conversations are private from colleagues. This affects collaboration and access expectations. + +## Predecessor decisions + +[D001](D001-first-practice.md); [D006](D006-booking-entry.md) establish the relevant accepted practice/role/initial-scope requirements. For D006, only the explicit private staff realm is a prerequisite; unsettled channel choices are not assumed. + +## Question + +Q14 — Staff chat privacy: Does each doctor/receptionist have a private conversation with Medora while sharing authorized schedules and requests, or should the whole practice see one shared conversation? + +## Recommendation and alternatives + +Give each staff member a private assistant conversation, with shared operational records and clear action attribution. Do not share all chat transcripts by default. + +The alternatives remain proposals until the user replies. + +## User reply — original words + + + +Round 4 reply, recorded 2026-10-15T13:46:49Z; original message timestamp unavailable: + +> q14: yeah, private conversations! they can share it thought with other users on the medora platform + +## Interpretation + +Each staff user has private conversations with Medora. A user may intentionally share conversation material with other Medora users. This does not establish snapshot versus ongoing access, the recipient audience, edit/comment permissions, revocation, or permission to expose otherwise unauthorized patient records. + +## Decision and rationale + +Confirmed: private staff conversations with optional explicit sharing to other Medora users. The default is private; sharing details remain unresolved. + +## Consequences and affected components + +Separate personal conversation visibility from shared operational data. Sharing requires a deliberate user action and must respect existing record-access and practice boundaries. D012/Q19 will clarify audience and scope. + +## Assumptions, evidence, and open questions + +Recipient eligibility, same-practice versus cross-practice sharing, selected messages versus whole conversations, live versus snapshot access, revocation, and audit details remain open. + +## Extra notes and follow-ups + +Related questions are continuing within this product session. No unrelated follow-up was introduced by this reply. + +## History + +- 2026-10-15T12:13:49Z — Assistant prepared round 4 question from accepted prerequisites. + +- 2026-10-15T13:46:49Z — Saved round 4 reply and confirmed the explicit choice. + - Prior interpretation: Pending. + - Prior decision summary: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md b/.planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md new file mode 100644 index 0000000..dd9288d --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md @@ -0,0 +1,91 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D009", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Routine booking approval", + "status": "confirmed", + "round": 4, + "created_at": "2026-10-15T12:13:49Z", + "updated_at": "2026-10-15T13:46:49Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Booking confirmations", + "Practice policies", + "Staff review" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T13:46:49Z" +} +--- + +# Context — why ask this? + +The product vision requires authorized scheduling and truthful confirmations, but the default routine-booking approval policy is not defined. The question is independent of which channel receives the request. + +## Predecessor decisions + +[D001](D001-first-practice.md); [D002](D002-anchor-problem.md) establish the accepted practice model and basic-booking scope. + +## Question + +Q16 — Routine booking approval: When a patient selects a valid available slot, should Medora confirm automatically within the practice rules, require staff approval for every request, or let each practice choose? + +## Recommendation and alternatives + +Let each practice choose. Automatic confirmation applies only to eligible routine bookings; requests outside its configured rules go to staff. + +The alternatives remain proposals until the user replies. + +## User reply — original words + + + +Round 4 reply, recorded 2026-10-15T13:46:49Z; original message timestamp unavailable: + +> q16: id say patient book an appointement, agent reserve a slot, when staff confirms, agent notifies the user, if staff changes schedule / refuse etc ... patient get notified as well + +## Interpretation + +The agent creates a provisional reservation from the patient conversation. Staff review determines confirmation, rejection, or scheduling changes; the agent informs the patient of those outcomes. A provisional slot is not a confirmed appointment. The user chooses a staff-review workflow, not the assistant's proposed configurable auto-confirmation default. Staff changes require notification; this alone does not settle patient acceptance of a replacement time. + +## Decision and rationale + +Confirmed: request → agent reserves slot pending staff review → staff confirms/rejects/changes → agent notifies the patient of the outcome. Patient-facing status must distinguish reserved/awaiting confirmation from confirmed, and communicate actual successful outcomes. + +## Consequences and affected components + +Scheduling needs provisional reservation and staff-review states. Determine hold exclusivity/expiry, approver roles, patient agreement to replacement times, and notification failure behavior. Never label the appointment confirmed before staff approval and successful persistence. + +## Assumptions, evidence, and open questions + +Reservation exclusivity, expiry, review deadlines, who can approve, review conflicts, handling replacement slots, and failed notification behavior are not yet chosen. Urgent medical concerns retain the established separate human escalation/safety boundaries. + +## Extra notes and follow-ups + +Related questions are continuing within this product session. No unrelated follow-up was introduced by this reply. + +## History + +- 2026-10-15T12:13:49Z — Assistant prepared round 4 question from accepted prerequisites. + +- 2026-10-15T13:46:49Z — Saved round 4 reply and confirmed the explicit choice. + - Prior interpretation: Pending. + - Prior decision summary: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D010-provisional-reservation-policy.md b/.planning/decisions/20261015T085738Z-3/D010-provisional-reservation-policy.md new file mode 100644 index 0000000..f5515f4 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D010-provisional-reservation-policy.md @@ -0,0 +1,84 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D010", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Pending reservations", + "status": "confirmed", + "round": 5, + "created_at": "2026-10-15T13:46:49Z", + "updated_at": "2026-10-15T13:52:30Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Availability", + "Pending requests", + "Patient status messages" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md" + ], + "reply_recorded_at": "2026-10-15T13:52:30Z" +} +--- + +# Context — why ask this? + +The accepted staff-review flow creates a period between reserving a slot and confirming an appointment. Availability and expiry must be explicit to avoid conflicting promises. + +## Predecessor decisions + +[D009](D009-routine-booking-authority.md). Their confirmed outcomes provide the prerequisites; no answer to another round 5 question is assumed. + +## Question + +Q17 — Pending reservations: While staff review a request, should its reserved slot be unavailable to other patients? Should the reservation expire if staff do not respond? + +## Recommendation and alternatives + +Hold the slot exclusively, with a practice-configured review deadline. If it expires, release it and tell the patient; never leave them believing it is confirmed. + +The user accepted this recommendation in the recorded reply, with the cancellation clarification recorded for Q20. + +## User reply — original words + +Round 5 reply, recorded 2026-10-15T13:52:30Z; original message timestamp unavailable: + +> q17: ok + +## Interpretation + +The user accepts the recommended exclusive reservation with a practice-configured review deadline. On expiry, the slot is released and the patient is informed. No numerical deadline, working-hours rule, reminder policy or last-minute cutoff was specified. + +## Decision and rationale + +Confirmed: pending reservations temporarily exclude competing bookings, expire according to practice configuration, release the slot on expiry, and notify the patient while preserving the distinction from confirmed appointments. + +## Consequences and affected components + +Confirmed: pending reservations temporarily exclude competing bookings, expire according to practice configuration, release the slot on expiry, and notify the patient while preserving the distinction from confirmed appointments. Staff-review clock behavior outside opening hours and cutoff before the actual appointment require further definition. No default duration is inferred. + +## Assumptions, evidence, and open questions + +Staff-review clock behavior outside opening hours and cutoff before the actual appointment require further definition. No default duration is inferred. + +## Extra notes and follow-ups + +No unrelated follow-up captured for this question. + +## History + +- 2026-10-15T13:46:49Z — Assistant prepared round 5 question from confirmed prerequisites. + +- 2026-10-15T13:52:30Z — Recorded round 5 reply and confirmed the choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D011-staff-approval-permissions.md b/.planning/decisions/20261015T085738Z-3/D011-staff-approval-permissions.md new file mode 100644 index 0000000..912c84e --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D011-staff-approval-permissions.md @@ -0,0 +1,86 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D011", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Who can approve?", + "status": "confirmed", + "round": 5, + "created_at": "2026-10-15T13:46:49Z", + "updated_at": "2026-10-15T13:52:30Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Role permissions", + "Review queue", + "Doctor/receptionist workflow" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md" + ], + "reply_recorded_at": "2026-10-15T13:52:30Z" +} +--- + +# Context — why ask this? + +Staff confirmation is accepted, but the responsible roles and assignments are not yet defined. This affects the actual daily workload. + +## Predecessor decisions + +[D001](D001-first-practice.md); [D009](D009-routine-booking-authority.md). Their confirmed outcomes provide the prerequisites; no answer to another round 5 question is assumed. + +## Question + +Q18 — Who can approve?: Can an assigned receptionist confirm or reject appointments, or must the doctor approve every request? + +## Recommendation and alternatives + +Allow doctors and their authorized receptionists to handle routine approvals. The practice defines the permission; clinical judgment stays with the doctor. + +The user accepted this recommendation in the recorded reply, with the cancellation clarification recorded for Q20. + +## User reply — original words + +Round 5 reply, recorded 2026-10-15T13:52:30Z; original message timestamp unavailable: + +> q18: ok + +## Interpretation + +The user accepts routine appointment approvals by doctors and their authorized/assigned receptionists, with practice-defined permissions. Receptionists are not given independent clinical decision authority. + +## Decision and rationale + +Confirmed: doctors and authorized receptionists may confirm or reject routine appointment requests within practice-defined permissions. + +## Consequences and affected components + +Confirmed: doctors and authorized receptionists may confirm or reject routine appointment requests within practice-defined permissions. Who configures memberships/permissions and how staff assignments are managed remain open; accepting this choice does not grant all receptionists access to all practices. + +## Assumptions, evidence, and open questions + +Who configures memberships/permissions and how staff assignments are managed remain open; accepting this choice does not grant all receptionists access to all practices. + +## Extra notes and follow-ups + +No unrelated follow-up captured for this question. + +## History + +- 2026-10-15T13:46:49Z — Assistant prepared round 5 question from confirmed prerequisites. + +- 2026-10-15T13:52:30Z — Recorded round 5 reply and confirmed the choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D012-conversation-sharing-scope.md b/.planning/decisions/20261015T085738Z-3/D012-conversation-sharing-scope.md new file mode 100644 index 0000000..c00de9d --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D012-conversation-sharing-scope.md @@ -0,0 +1,86 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D012", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Sharing conversations", + "status": "confirmed", + "round": 5, + "created_at": "2026-10-15T13:46:49Z", + "updated_at": "2026-10-15T13:52:30Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D008-staff-chat-privacy.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Staff conversation sharing", + "Practice boundaries", + "Patient record access" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D008-staff-chat-privacy.md" + ], + "reply_recorded_at": "2026-10-15T13:52:30Z" +} +--- + +# Context — why ask this? + +Private staff conversations and intentional sharing are accepted. The audience, duration and amount of shared content remain unspecified. + +## Predecessor decisions + +[D001](D001-first-practice.md); [D008](D008-staff-chat-privacy.md). Their confirmed outcomes provide the prerequisites; no answer to another round 5 question is assumed. + +## Question + +Q19 — Sharing conversations: Should sharing expose selected messages or an entire ongoing conversation? Should recipients be limited to authorized colleagues in the same practice? + +## Recommendation and alternatives + +Start with selected read-only messages shared with named, authorized colleagues in the same practice. Sharing must not grant access to otherwise restricted patient records. + +The user accepted this recommendation in the recorded reply, with the cancellation clarification recorded for Q20. + +## User reply — original words + +Round 5 reply, recorded 2026-10-15T13:52:30Z; original message timestamp unavailable: + +> q19: yeah + +## Interpretation + +The user accepts the stated recommendation: selected read-only messages shared explicitly with named authorized colleagues in the same practice, respecting existing patient-record permissions. This does not establish public links, live transcript access, cross-practice sharing, recipient re-sharing, or revocation details. + +## Decision and rationale + +Confirmed initial sharing scope: selected read-only messages, named authorized recipients in the same practice, and patient-record permissions preserved. Private conversations remain private by default. + +## Consequences and affected components + +Confirmed initial sharing scope: selected read-only messages, named authorized recipients in the same practice, and patient-record permissions preserved. Private conversations remain private by default. Revocation, message redaction, recipient re-sharing, and audit presentation remain to be specified. No ongoing collaborative transcript or external sharing is inferred. + +## Assumptions, evidence, and open questions + +Revocation, message redaction, recipient re-sharing, and audit presentation remain to be specified. No ongoing collaborative transcript or external sharing is inferred. + +## Extra notes and follow-ups + +No unrelated follow-up captured for this question. + +## History + +- 2026-10-15T13:46:49Z — Assistant prepared round 5 question from confirmed prerequisites. + +- 2026-10-15T13:52:30Z — Recorded round 5 reply and confirmed the choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D013-replacement-slot-agreement.md b/.planning/decisions/20261015T085738Z-3/D013-replacement-slot-agreement.md new file mode 100644 index 0000000..a297742 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D013-replacement-slot-agreement.md @@ -0,0 +1,84 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D013", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "A different appointment time", + "status": "confirmed", + "round": 5, + "created_at": "2026-10-15T13:46:49Z", + "updated_at": "2026-10-15T13:52:30Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Rescheduling", + "Patient agreement", + "Appointment status" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md" + ], + "reply_recorded_at": "2026-10-15T13:52:30Z" +} +--- + +# Context — why ask this? + +The user requires notifications for staff schedule changes. Notification alone does not establish whether the patient agreed to a replacement time. + +## Predecessor decisions + +[D009](D009-routine-booking-authority.md). Their confirmed outcomes provide the prerequisites; no answer to another round 5 question is assumed. + +## Question + +Q20 — A different appointment time: If staff proposes a different time—or changes an already confirmed appointment—should Medora ask the patient to accept the replacement before treating that new time as agreed? + +## Recommendation and alternatives + +Yes. Explain the change, propose the new time, and obtain the patient's agreement. Notify them clearly if the original appointment has been cancelled; do not imply a replacement is accepted merely because a message was sent. + +The user accepted this recommendation in the recorded reply, with the cancellation clarification recorded for Q20. + +## User reply — original words + +Round 5 reply, recorded 2026-10-15T13:52:30Z; original message timestamp unavailable: + +> q20: yeah, and patient is free to cancel if the time does not fit his schedule (work, school etc ..) + +## Interpretation + +The user accepts asking the patient to agree to a replacement appointment time and explicitly adds that the patient may cancel if it conflicts with their work, school, or other schedule. This applies to the discussed staff-initiated schedule-change situation; it does not define a monetary cancellation-fee policy or every self-initiated cancellation rule. + +## Decision and rationale + +Confirmed: a replacement time requires patient agreement. If it does not fit, the patient may decline and cancel rather than being forced into the replacement. Communicate changes/cancellation honestly and only after successful operations. + +## Consequences and affected components + +Confirmed: a replacement time requires patient agreement. If it does not fit, the patient may decline and cancel rather than being forced into the replacement. Communicate changes/cancellation honestly and only after successful operations. Replacement-offer expiry, alternate-slot selection, patient cancellation identity checks, and ordinary cancellation-policy details remain open. Do not interpret freedom to cancel as a settled financial policy. + +## Assumptions, evidence, and open questions + +Replacement-offer expiry, alternate-slot selection, patient cancellation identity checks, and ordinary cancellation-policy details remain open. Do not interpret freedom to cancel as a settled financial policy. + +## Extra notes and follow-ups + +No unrelated follow-up captured for this question. + +## History + +- 2026-10-15T13:46:49Z — Assistant prepared round 5 question from confirmed prerequisites. + +- 2026-10-15T13:52:30Z — Recorded round 5 reply and confirmed the choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D014-review-deadline-outside-working-hours.md b/.planning/decisions/20261015T085738Z-3/D014-review-deadline-outside-working-hours.md new file mode 100644 index 0000000..bcc9ee7 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D014-review-deadline-outside-working-hours.md @@ -0,0 +1,86 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D014", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Requests outside opening hours", + "status": "confirmed", + "round": 6, + "created_at": "2026-10-15T13:52:30Z", + "updated_at": "2026-10-15T14:24:28Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D010-provisional-reservation-policy.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Review deadlines", + "Provisional reservations", + "Patient expectations" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D010-provisional-reservation-policy.md" + ], + "reply_recorded_at": "2026-10-15T14:24:28Z", + "selected_by": "assistant", + "selection_basis": "Explicit user delegation: q21: idk, you pick" +} +--- + +# Context — why ask this? + +Exclusive, expiring holds are confirmed, but a patient can message at any time. The deadline must behave predictably while staff are unavailable. + +## Predecessor decisions + +[D010](D010-provisional-reservation-policy.md). The confirmed outcomes establish this question's prerequisites. No answer to another round 6 question is assumed. + +## Question + +Q21 — Requests outside opening hours: If a patient requests a slot while the practice is closed, should the staff-review deadline count only staffed working hours rather than expiring overnight? + +## Recommendation and alternatives + +Count staffed working hours, and always end the hold before the appointment starts. Tell the patient when staff are expected to review it; do not promise a response time the practice cannot support. + +The current decision below records the reply. For Q21 the user delegated the choice; the rationale is attributed to the assistant. Earlier framing is retained as history. + +## User reply — original words + +Round 6 reply, recorded 2026-10-15T14:24:28Z; original message timestamp unavailable: + +> q21: idk, you pick + +## Interpretation + +The user explicitly delegates the review-clock choice to the assistant. The following policy is an assistant selection under that delegation, not a verbatim user choice. + +## Decision and rationale + +Selected under delegation: count the configured review budget only during staffed working hours, cap the hold at a practice-configured cutoff before the appointment starts, and expire at the earlier limit. Release the slot and notify the patient on expiry. State expected review timing honestly. Avoid offering a reservable slot if the practice cannot review it before its cutoff. + +## Consequences and affected components + +Selected under delegation: count the configured review budget only during staffed working hours, cap the hold at a practice-configured cutoff before the appointment starts, and expire at the earlier limit. Release the slot and notify the patient on expiry. State expected review timing honestly. Avoid offering a reservable slot if the practice cannot review it before its cutoff. The rationale is the assistant's: avoid overnight expiry caused solely by closed hours while preventing a pending reservation from surviving until/after the appointment. Exact numerical budgets, cutoff buffers and exceptional review coverage are practice settings; no default duration is invented. + +## Assumptions, evidence, and open questions + +The rationale is the assistant's: avoid overnight expiry caused solely by closed hours while preventing a pending reservation from surviving until/after the appointment. Exact numerical budgets, cutoff buffers and exceptional review coverage are practice settings; no default duration is invented. + +## Extra notes and follow-ups + +No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T13:52:30Z — Assistant prepared the round 6 question from confirmed prerequisites. + +- 2026-10-15T14:24:28Z — Saved round 6 reply and current decision. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md b/.planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md new file mode 100644 index 0000000..c9b7d26 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md @@ -0,0 +1,88 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D015", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Which practice are they messaging?", + "status": "confirmed", + "round": 6, + "created_at": "2026-10-15T13:52:30Z", + "updated_at": "2026-10-15T14:24:28Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Patient entry", + "Practice identity", + "Doctor selection" + ], + "follow_ups": [ + ".planning/follow-ups/20261015T142428Z-validate-whatsapp-linked-line-onboarding/follow-up.md" + ], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md" + ], + "reply_recorded_at": "2026-10-15T14:24:28Z" +} +--- + +# Context — why ask this? + +A WhatsApp-first product needs an explicit relationship between the conversation and the practice it represents. The organization model does not decide whether the patient starts with a practice-specific or shared contact. + +## Predecessor decisions + +[D001](D001-first-practice.md); [D006](D006-booking-entry.md). The confirmed outcomes establish this question's prerequisites. No answer to another round 6 question is assumed. + +## Question + +Q22 — Which practice are they messaging?: Should patients message the practice's own WhatsApp contact, with Medora acting as that practice's secretary, or a shared Medora contact that first finds their practice and doctor? + +## Recommendation and alternatives + +Start with the practice's own contact and identity. Within a multi-doctor practice, ask which doctor they want if that is not already clear. + +The current decision below records the reply. For Q21 the user delegated the choice; the rationale is attributed to the assistant. Earlier framing is retained as history. + +## User reply — original words + +Round 6 reply, recorded 2026-10-15T14:24:28Z; original message timestamp unavailable: + +> q22: medora is a platform, it requires its users (practice) to link a client facing communication app (currently only whatsapp will be used) so, the whatsapp app will need a linked line (like whatsapp busniess etc ...) so it can be either one of their personal phone numbers, or a shared one, the idea is that modera attaches to a line for edge communication + +## Interpretation + +Medora is the practice management platform. A practice links a client-facing communication app/line, currently WhatsApp only. The linked phone number may be personal to a practitioner or shared. Medora attaches to that line for external patient conversation; this is not a requirement for a single platform-wide Medora contact. Number ownership does not itself establish doctor routing or platform permissions. + +## Decision and rationale + +Confirmed: a linked communication-line model for patient communication, with WhatsApp as the only initial app and support for personally used or shared phone numbers as a product requirement. Staff use Medora privately; patients communicate over the linked external line. + +## Consequences and affected components + +Confirmed: a linked communication-line model for patient communication, with WhatsApp as the only initial app and support for personally used or shared phone numbers as a product requirement. Staff use Medora privately; patients communicate over the linked external line. How a line maps to practice/doctors, whether a practice may attach multiple lines, and coexistence with manual replies remain open product details. No particular WhatsApp account type, API, migration path, or personal-account integration compatibility is claimed; technical feasibility is a separate follow-up. + +## Assumptions, evidence, and open questions + +How a line maps to practice/doctors, whether a practice may attach multiple lines, and coexistence with manual replies remain open product details. No particular WhatsApp account type, API, migration path, or personal-account integration compatibility is claimed; technical feasibility is a separate follow-up. + +## Extra notes and follow-ups + +[Linked-line onboarding research](../../follow-ups/20261015T142428Z-validate-whatsapp-linked-line-onboarding/follow-up.md) preserves the later technical feasibility work. + +## History + +- 2026-10-15T13:52:30Z — Assistant prepared the round 6 question from confirmed prerequisites. + +- 2026-10-15T14:24:28Z — Saved round 6 reply and current decision. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D016-booking-for-someone-else.md b/.planning/decisions/20261015T085738Z-3/D016-booking-for-someone-else.md new file mode 100644 index 0000000..7c7cac8 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D016-booking-for-someone-else.md @@ -0,0 +1,86 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D016", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Booking for someone else", + "status": "confirmed", + "round": 6, + "created_at": "2026-10-15T13:52:30Z", + "updated_at": "2026-10-15T14:24:28Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md", + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Patient identity", + "Profile matching", + "Caregiver booking" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md", + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md" + ], + "reply_recorded_at": "2026-10-15T14:24:28Z" +} +--- + +# Context — why ask this? + +The agreed administrative profile needs to identify the patient. The WhatsApp sender may be a parent or caregiver rather than that patient, so phone-based matching cannot be silently assumed. + +## Predecessor decisions + +[D006](D006-booking-entry.md); [D007](D007-basic-patient-profile.md). The confirmed outcomes establish this question's prerequisites. No answer to another round 6 question is assumed. + +## Question + +Q23 — Booking for someone else: Should the first version let a parent or caregiver book for someone else using their own WhatsApp number? + +## Recommendation and alternatives + +Yes: distinguish the person chatting from the patient being booked. Ask who the appointment is for, and verify authorization before revealing an existing patient's information; a matching phone number alone is insufficient. + +The current decision below records the reply. For Q21 the user delegated the choice; the rationale is attributed to the assistant. Earlier framing is retained as history. + +## User reply — original words + +Round 6 reply, recorded 2026-10-15T14:24:28Z; original message timestamp unavailable: + +> q23: yeah its possible and the line holder is the communication channel + +## Interpretation + +The user confirms booking for someone else. The holder/sender of the WhatsApp line is the communication contact, which can be different from the patient. A contact can therefore communicate about bookings for another person. This does not automatically authorize that contact to view every existing patient record. + +## Decision and rationale + +Confirmed: support booking on behalf of another person and keep the communication contact separate from the patient profile. Deliver the booking conversation through the contact's line. + +## Consequences and affected components + +Confirmed: support booking on behalf of another person and keep the communication contact separate from the patient profile. Deliver the booking conversation through the contact's line. Returning-patient matching, multiple patients per contact, representative authorization, corrections, and what existing information can be disclosed remain to be defined. A phone number is a communication endpoint, not by itself proof of patient identity or guardianship. + +## Assumptions, evidence, and open questions + +Returning-patient matching, multiple patients per contact, representative authorization, corrections, and what existing information can be disclosed remain to be defined. A phone number is a communication endpoint, not by itself proof of patient identity or guardianship. + +## Extra notes and follow-ups + +No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T13:52:30Z — Assistant prepared the round 6 question from confirmed prerequisites. + +- 2026-10-15T14:24:28Z — Saved round 6 reply and current decision. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D017-optional-conversational-intake.md b/.planning/decisions/20261015T085738Z-3/D017-optional-conversational-intake.md new file mode 100644 index 0000000..e323986 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D017-optional-conversational-intake.md @@ -0,0 +1,86 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D017", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Intake without blocking booking", + "status": "confirmed", + "round": 6, + "created_at": "2026-10-15T13:52:30Z", + "updated_at": "2026-10-15T14:24:28Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md", + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "WhatsApp booking", + "Patient intake", + "Staff preparation" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md", + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md" + ], + "reply_recorded_at": "2026-10-15T14:24:28Z" +} +--- + +# Context — why ask this? + +Basic appointment-specific intake is confirmed, but its sequence and effect on booking are not. The conversational experience should have explicit required and optional information boundaries. + +## Predecessor decisions + +[D007](D007-basic-patient-profile.md); [D009](D009-routine-booking-authority.md). The confirmed outcomes establish this question's prerequisites. No answer to another round 6 question is assumed. + +## Question + +Q24 — Intake without blocking booking: Should Medora reserve the slot once it has the minimum booking information, then collect the short intake conversationally, allowing nonessential questions to be skipped? + +## Recommendation and alternatives + +Yes. Keep booking easy, collect only relevant context, and show staff what is missing. Unanswered optional intake should not by itself prevent staff from confirming. + +The current decision below records the reply. For Q21 the user delegated the choice; the rationale is attributed to the assistant. Earlier framing is retained as history. + +## User reply — original words + +Round 6 reply, recorded 2026-10-15T14:24:28Z; original message timestamp unavailable: + +> q24: ok + +## Interpretation + +The user accepts reserving once the minimum booking information is available, then gathering short relevant intake conversationally. Nonessential questions can be skipped, and missing optional intake alone does not block staff confirmation. + +## Decision and rationale + +Confirmed: minimum booking data first, provisional reservation next, then brief conversational intake with optional nonessential questions and visible missing-information status for staff. + +## Consequences and affected components + +Confirmed: minimum booking data first, provisional reservation next, then brief conversational intake with optional nonessential questions and visible missing-information status for staff. Exact required booking fields, appointment-specific approved questions, and when staff sees incomplete intake remain product details. Skipping optional intake is not evidence that there are no concerns; existing safety/escalation boundaries remain in force. + +## Assumptions, evidence, and open questions + +Exact required booking fields, appointment-specific approved questions, and when staff sees incomplete intake remain product details. Skipping optional intake is not evidence that there are no concerns; existing safety/escalation boundaries remain in force. + +## Extra notes and follow-ups + +No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T13:52:30Z — Assistant prepared the round 6 question from confirmed prerequisites. + +- 2026-10-15T14:24:28Z — Saved round 6 reply and current decision. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D018-linked-line-doctor-routing.md b/.planning/decisions/20261015T085738Z-3/D018-linked-line-doctor-routing.md new file mode 100644 index 0000000..1f96581 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D018-linked-line-doctor-routing.md @@ -0,0 +1,86 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D018", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Routing a linked line", + "status": "confirmed", + "round": 7, + "created_at": "2026-10-15T14:24:28Z", + "updated_at": "2026-10-15T14:35:28Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Linked lines", + "Doctor selection", + "Practice onboarding" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md" + ], + "reply_recorded_at": "2026-10-15T14:35:28Z" +} +--- + +# Context — why ask this? + +A personal or shared connected line is confirmed, but the doctors it represents have not been defined. This is a product routing decision, independent of the eventual integration implementation. + +## Predecessor decisions + +[D001](D001-first-practice.md); [D015](D015-practice-and-doctor-routing.md). Only their accepted requirements are prerequisites; unresolved details and other round 7 answers are not assumed. + +## Question + +Q25 — Routing a linked line: Should each linked line be configurable for one doctor or a group of doctors, so Medora knows when to use a default doctor and when to ask the patient to choose? + +## Recommendation and alternatives + +Yes. A doctor-specific line defaults to that doctor; a shared practice line uses the patient's preference or asks who they want. Never silently substitute another doctor. + +The user reply and current decision are recorded below; earlier recommendation wording is historical and is not automatically accepted. + +## User reply — original words + +Round 7 reply, recorded 2026-10-15T14:35:28Z; original message timestamp unavailable: + +> q25: ok + +## Interpretation + +The user accepts line-level doctor routing: a connected line can represent one doctor or a doctor group, with the doctor-specific default or patient clarification used appropriately. + +## Decision and rationale + +Confirmed: configurable one-doctor/group line routing. Respect the requested doctor; do not silently substitute another. + +## Consequences and affected components + +Confirmed: configurable one-doctor/group line routing. Respect the requested doctor; do not silently substitute another. Default-assignment setup and preferences for patients who have no doctor preference remain to be specified. + +## Assumptions, evidence, and open questions + +Default-assignment setup and preferences for patients who have no doctor preference remain to be specified. + +## Extra notes and follow-ups + +No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T14:24:28Z — Prepared the round 7 question from accepted prerequisites. + +- 2026-10-15T14:35:28Z — Saved round 7 reply; status confirmed. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D019-contact-with-multiple-patient-profiles.md b/.planning/decisions/20261015T085738Z-3/D019-contact-with-multiple-patient-profiles.md new file mode 100644 index 0000000..2a70faa --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D019-contact-with-multiple-patient-profiles.md @@ -0,0 +1,86 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D019", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Returning patients", + "status": "confirmed", + "round": 7, + "created_at": "2026-10-15T14:24:28Z", + "updated_at": "2026-10-15T14:35:28Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md", + ".planning/decisions/20261015T085738Z-3/D016-booking-for-someone-else.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Communication contacts", + "Patient profiles", + "Returning-patient booking" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md", + ".planning/decisions/20261015T085738Z-3/D016-booking-for-someone-else.md" + ], + "reply_recorded_at": "2026-10-15T14:35:28Z" +} +--- + +# Context — why ask this? + +Booking for another person and a distinct communication contact are confirmed. A household contact may use the same line for multiple patients; profiles and appointment histories must not be merged by phone number. + +## Predecessor decisions + +[D007](D007-basic-patient-profile.md); [D016](D016-booking-for-someone-else.md). Only their accepted requirements are prerequisites; unresolved details and other round 7 answers are not assumed. + +## Question + +Q26 — Returning patients: Should Medora reuse details from an already verified contact-patient relationship, asking who this booking is for, or collect identity details again on every booking? + +## Recommendation and alternatives + +Reuse known details for verified relationships and confirm which person the appointment is for. Clarify or seek staff help when matching or authorization is uncertain, and reverify when needed for sensitive access or changes. The exact verification method remains to be defined. + +The user reply and current decision are recorded below; earlier recommendation wording is historical and is not automatically accepted. + +## User reply — original words + +Round 7 reply, recorded 2026-10-15T14:35:28Z; original message timestamp unavailable: + +> q26: ok + +## Interpretation + +The user accepts reuse of known details for verified contact-patient relationships, while confirming the intended patient and rechecking uncertain matching or sensitive access/changes. + +## Decision and rationale + +Confirmed: returning users do not repeat all known identity details on each booking; reuse verified relationships and clarify who the booking is for. + +## Consequences and affected components + +Confirmed: returning users do not repeat all known identity details on each booking; reuse verified relationships and clarify who the booking is for. Exact verification, re-verification triggers, ambiguous matches and corrections remain open. An arbitrary phone-number match is not sufficient. + +## Assumptions, evidence, and open questions + +Exact verification, re-verification triggers, ambiguous matches and corrections remain open. An arbitrary phone-number match is not sufficient. + +## Extra notes and follow-ups + +No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T14:24:28Z — Prepared the round 7 question from accepted prerequisites. + +- 2026-10-15T14:35:28Z — Saved round 7 reply; status confirmed. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D020-patient-conversation-languages.md b/.planning/decisions/20261015T085738Z-3/D020-patient-conversation-languages.md new file mode 100644 index 0000000..f880057 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D020-patient-conversation-languages.md @@ -0,0 +1,86 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D020", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Patient conversation languages", + "status": "confirmed", + "round": 7, + "created_at": "2026-10-15T14:24:28Z", + "updated_at": "2026-10-15T14:35:28Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md", + ".planning/decisions/20261015T085738Z-3/D003-pilot-market.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "WhatsApp assistant", + "Language preferences", + "Patient messages" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md", + ".planning/decisions/20261015T085738Z-3/D003-pilot-market.md" + ], + "reply_recorded_at": "2026-10-15T14:35:28Z" +} +--- + +# Context — why ask this? + +Four UI languages are confirmed, but that did not automatically establish supported patient conversation languages. The geography portion of D003 is deferred and is not a prerequisite here. + +## Predecessor decisions + +[D006](D006-booking-entry.md); [D003](D003-pilot-market.md). Only their accepted requirements are prerequisites; unresolved details and other round 7 answers are not assumed. + +## Question + +Q27 — Patient conversation languages: Should the WhatsApp agent also converse in English, French, Arabic, and Spanish, adapting to the patient's language and allowing them to switch? + +## Recommendation and alternatives + +Yes. Use those four as the initial supported conversation languages, separately from the staff UI language. Ask when the patient's preference is unclear. + +The user reply and current decision are recorded below; earlier recommendation wording is historical and is not automatically accepted. + +## User reply — original words + +Round 7 reply, recorded 2026-10-15T14:35:28Z; original message timestamp unavailable: + +> q27: the agent is instructed to reply in the user's own language and it saves that preference for future interacrions unless the user / patient say so + +## Interpretation + +The user specifies language-adaptive replies and remembered preference until the user/patient changes it. This is not acceptance of the assistant's fixed four-conversation-language limit. Initial UI locales remain EN/FR/AR/ES; patient conversation language behavior is a separate requirement. Preference scope for a contact booking for several patients remains open. + +## Decision and rationale + +Confirmed: reply in the user's own language, remember that preference across future interactions, and honor changes requested by the user/patient. Do not impose the UI language list as the conversation-language whitelist. + +## Consequences and affected components + +Confirmed: reply in the user's own language, remember that preference across future interactions, and honor changes requested by the user/patient. Do not impose the UI language list as the conversation-language whitelist. How to handle uncertain language, model capability limits, mixed-language messages, contact versus patient preference, and translating clinical/practice templates still needs product decisions. No guarantee of equal fluency or support quality for every language is made. + +## Assumptions, evidence, and open questions + +How to handle uncertain language, model capability limits, mixed-language messages, contact versus patient preference, and translating clinical/practice templates still needs product decisions. No guarantee of equal fluency or support quality for every language is made. + +## Extra notes and follow-ups + +No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T14:24:28Z — Prepared the round 7 question from accepted prerequisites. + +- 2026-10-15T14:35:28Z — Saved round 7 reply; status confirmed. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md b/.planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md new file mode 100644 index 0000000..f11c2b2 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md @@ -0,0 +1,93 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D021", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Human takeover", + "status": "confirmed", + "round": 7, + "created_at": "2026-10-15T14:24:28Z", + "updated_at": "2026-10-15T14:38:24Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md", + ".planning/decisions/20261015T085738Z-3/D011-staff-approval-permissions.md", + ".planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md" + ], + "related_decisions": [ + ".planning/decisions/20261015T085738Z-3/D022-optional-patient-group-handoff.md", + ".planning/decisions/20261015T085738Z-3/D024-agent-context-during-human-handoff.md" + ], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Human handoff", + "Staff workspace", + "Patient conversation ownership" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md", + ".planning/decisions/20261015T085738Z-3/D011-staff-approval-permissions.md", + ".planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md" + ], + "reply_recorded_at": "2026-10-15T14:35:28Z" +} +--- + +# Context — why ask this? + +Staff review and a platform connected to patient communication lines are confirmed. Ownership of the conversation during a human handoff needs an explicit product policy. + +## Predecessor decisions + +[D006](D006-booking-entry.md); [D011](D011-staff-approval-permissions.md); [D015](D015-practice-and-doctor-routing.md). Only their accepted requirements are prerequisites; unresolved details and other round 7 answers are not assumed. + +## Question + +Q28 — Human takeover: Should staff be able to take over a patient's WhatsApp conversation from Medora when the patient asks for a person or the agent cannot complete the request, pausing the agent until staff hand it back? + +## Recommendation and alternatives + +Yes. Give authorized staff a clear handoff with the relevant context, show the patient that a human response is pending, and avoid simultaneous human/agent replies. + +The user reply and current decision are recorded below; earlier recommendation wording is historical and is not automatically accepted. + +## User reply — original words + +Round 7 reply, recorded 2026-10-15T14:35:28Z; original message timestamp unavailable: + +> q28: yeah! and maybe in this case the agent creates a new unique group per patient and it adds a staff (or all idk) so they can communicate and the agent can be tagged to update its awareness instead of replying directly on the agent's default line right? + +## Interpretation + +Human takeover is accepted. The user tentatively proposes one distinct WhatsApp group per patient, adding staff so humans can communicate there and tagging the agent to update its awareness. The words maybe, or all idk, and right? leave the group mechanism, staff audience and agent behavior open. This is not confirmation of adding all staff or an assertion that any linked WhatsApp line supports group automation. + +## Decision and rationale + +Confirmed: authorized human staff can take over when needed. The user's per-patient group and tag-driven-awareness proposal remains unsettled and is tracked in D022/D024, not treated as a required or working integration. + +## Consequences and affected components + +Confirmed portion: human staff can take over when needed. Proposed, not settled: a per-patient group with selected staff and tag-driven agent participation/context updates. Group feasibility and product behavior are being checked before endorsing it. Official WhatsApp group/API feasibility is an unsettled prerequisite for choosing the initial handoff mechanism. Staff assignment, invitations/consent, group ownership and lifecycle, visibility of participant contact details, reading versus responding, and whether a tag can authorize actions remain open. + +## Assumptions, evidence, and open questions + +Official WhatsApp group/API feasibility is an unsettled prerequisite for choosing the initial handoff mechanism. Staff assignment, invitations/consent, group ownership and lifecycle, visibility of participant contact details, reading versus responding, and whether a tag can authorize actions remain open. + +## Extra notes and follow-ups + +[Official-source feasibility note](whatsapp-group-feasibility.md) documents current group constraints. The [linked-line onboarding follow-up](../../follow-ups/20261015T142428Z-validate-whatsapp-linked-line-onboarding/follow-up.md) now includes the remaining group/tag integration questions. + +## History + +- 2026-10-15T14:24:28Z — Prepared the round 7 question from accepted prerequisites. + +- 2026-10-15T14:35:28Z — Saved round 7 reply; status needs-clarification. Prior interpretation: Pending. Prior decision: Pending. + +- 2026-10-15T14:38:24Z — Classified the accepted takeover capability as confirmed and separated the tentative group mechanism into follow-on decisions; official-source feasibility findings recorded. diff --git a/.planning/decisions/20261015T085738Z-3/D022-optional-patient-group-handoff.md b/.planning/decisions/20261015T085738Z-3/D022-optional-patient-group-handoff.md new file mode 100644 index 0000000..ac9a44d --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D022-optional-patient-group-handoff.md @@ -0,0 +1,85 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D022", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Optional groups", + "status": "confirmed", + "round": 8, + "created_at": "2026-10-15T14:38:24Z", + "updated_at": "2026-10-15T14:45:47Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Human handoff", + "Optional patient groups", + "Patient channel continuity" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md", + ".planning/decisions/20261015T085738Z-3/whatsapp-group-feasibility.md" + ], + "reply_recorded_at": "2026-10-15T14:45:47Z" +} +--- + +# Context — why ask this? + +The user proposed a group per patient. Official-source research shows account and invitation limits, so the initial flow needs an explicit choice about group dependence and fallback. + +## Predecessor decisions + +[D021](D021-staff-takeover-of-patient-chat.md). Their accepted outcomes are prerequisites; no other round 8 outcome is assumed. Where groups are relevant, see [the feasibility note](whatsapp-group-feasibility.md). + +## Question + +Q29 — Optional groups: Given WhatsApp's restrictions, should per-patient groups be optional for eligible practices and consenting participants, with staff able to handle the existing one-to-one patient chat when groups are unavailable or declined? + +## Recommendation and alternatives + +Yes. Keep the patient-group idea, but preserve a usable human handoff for every supported practice without requiring group access. + +The current decision records the user reply below. Earlier recommendations are not automatically accepted where the user supplied a different configuration. + +## User reply — original words + +Round 8 reply, recorded 2026-10-15T14:45:47Z; original message timestamp unavailable: + +> q29: ok + +## Interpretation + +The user accepts optional per-patient groups for eligible practices and consenting participants, with authorized human handling of the existing one-to-one patient conversation when groups are unavailable or declined. + +## Decision and rationale + +Confirmed: optional patient-specific groups with a one-to-one handoff fallback. Group availability is eligibility-dependent; the patient is not required to join a group to receive human assistance. + +## Consequences and affected components + +Confirmed: optional patient-specific groups with a one-to-one handoff fallback. Group availability is eligibility-dependent; the patient is not required to join a group to receive human assistance. Group delivery timing, lifecycle, invitation/join failures and native tag detection remain unresolved. No group implementation or supported-account compatibility is claimed. + +## Assumptions, evidence, and open questions + +Group delivery timing, lifecycle, invitation/join failures and native tag detection remain unresolved. No group implementation or supported-account compatibility is claimed. + +## Extra notes and follow-ups + +The linked-line follow-up holds remaining WhatsApp integration verification. These product questions stay in the active session. + +## History + +- 2026-10-15T14:38:24Z — Prepared the round 8 question after preserving the round 7 reply and checking relevant official documentation. + +- 2026-10-15T14:45:47Z — Saved round 8 reply and confirmed its explicit scope. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D023-handoff-staff-assignment.md b/.planning/decisions/20261015T085738Z-3/D023-handoff-staff-assignment.md new file mode 100644 index 0000000..0557bf8 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D023-handoff-staff-assignment.md @@ -0,0 +1,88 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D023", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Which staff joins?", + "status": "confirmed", + "round": 8, + "created_at": "2026-10-15T14:38:24Z", + "updated_at": "2026-10-15T14:45:47Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D011-staff-approval-permissions.md", + ".planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Handoff assignment", + "Staff visibility", + "Practice workflow" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D011-staff-approval-permissions.md", + ".planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md" + ], + "reply_recorded_at": "2026-10-15T14:45:47Z" +} +--- + +# Context — why ask this? + +The user explicitly left one staff versus all staff undecided. This question applies to either groups or the existing patient conversation. + +## Predecessor decisions + +[D001](D001-first-practice.md); [D011](D011-staff-approval-permissions.md); [D021](D021-staff-takeover-of-patient-chat.md). Their accepted outcomes are prerequisites; no other round 8 outcome is assumed. Where groups are relevant, see [the feasibility note](whatsapp-group-feasibility.md). + +## Question + +Q30 — Which staff joins?: Should a handoff go to an assigned receptionist first, with the doctor involved when needed, rather than automatically exposing the conversation to all staff? + +## Recommendation and alternatives + +Use named responsible staff, with an authorized backup if unavailable. For optional groups, invite only the people needed for that patient/request. + +The current decision records the user reply below. Earlier recommendations are not automatically accepted where the user supplied a different configuration. + +## User reply — original words + +Round 8 reply, recorded 2026-10-15T14:45:47Z; original message timestamp unavailable: + +> q30: a default staff (configured on modera platform) + +## Interpretation + +The user selects a default staff member configured in Medora as the handoff recipient. They do not require that person to be a receptionist, add all staff by default, or settle automatic backup/escalation behavior. + +## Decision and rationale + +Confirmed: route handoffs to the default staff member configured on Medora, subject to the existing permissions and practice scope. + +## Consequences and affected components + +Confirmed: route handoffs to the default staff member configured on Medora, subject to the existing permissions and practice scope. Configuration scope (practice versus line/doctor), who may change the setting, unavailability handling and reassignment remain open. Do not invent a mandatory receptionist-first role or all-staff group. + +## Assumptions, evidence, and open questions + +Configuration scope (practice versus line/doctor), who may change the setting, unavailability handling and reassignment remain open. Do not invent a mandatory receptionist-first role or all-staff group. + +## Extra notes and follow-ups + +The linked-line follow-up holds remaining WhatsApp integration verification. These product questions stay in the active session. + +## History + +- 2026-10-15T14:38:24Z — Prepared the round 8 question after preserving the round 7 reply and checking relevant official documentation. + +- 2026-10-15T14:45:47Z — Saved round 8 reply and confirmed its explicit scope. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D024-agent-context-during-human-handoff.md b/.planning/decisions/20261015T085738Z-3/D024-agent-context-during-human-handoff.md new file mode 100644 index 0000000..4d398cd --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D024-agent-context-during-human-handoff.md @@ -0,0 +1,87 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D024", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Agent awareness during handoff", + "status": "confirmed", + "round": 8, + "created_at": "2026-10-15T14:38:24Z", + "updated_at": "2026-10-15T14:45:47Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md", + ".planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Agent context", + "Human conversation ownership", + "Authorized record updates" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md", + ".planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md", + ".planning/decisions/20261015T085738Z-3/whatsapp-group-feasibility.md" + ], + "reply_recorded_at": "2026-10-15T14:45:47Z" +} +--- + +# Context — why ask this? + +The user proposed tagging the agent to update its awareness. Reading conversation context, replying, and changing authoritative records are distinct behaviors; tagging feasibility is not yet verified. + +## Predecessor decisions + +[D007](D007-basic-patient-profile.md); [D021](D021-staff-takeover-of-patient-chat.md). Their accepted outcomes are prerequisites; no other round 8 outcome is assumed. Where groups are relevant, see [the feasibility note](whatsapp-group-feasibility.md). + +## Question + +Q31 — Agent awareness during handoff: While humans are talking, should Medora silently retain context from the authorized conversation and respond only when invoked, or process only the messages explicitly directed to it? + +## Recommendation and alternatives + +Retain the authorized conversation context silently, and reply only when explicitly invoked or handed control back. A tag alone should not authorize schedule changes or turn unverified chat statements into confirmed clinical facts. + +The current decision records the user reply below. Earlier recommendations are not automatically accepted where the user supplied a different configuration. + +## User reply — original words + +Round 8 reply, recorded 2026-10-15T14:45:47Z; original message timestamp unavailable: + +> q31: yeah + +## Interpretation + +The user accepts silently retaining authorized conversation context during human handling and replying when invoked or handed control back. Context updates alone do not authorize schedule mutations or make clinical statements verified facts. + +## Decision and rationale + +Confirmed: agent maintains permitted context silently while humans own the conversation; agent replies only on explicit invocation or control return. Actions still require established authorization, validation and confirmation. + +## Consequences and affected components + +Confirmed: agent maintains permitted context silently while humans own the conversation; agent replies only on explicit invocation or control return. Actions still require established authorization, validation and confirmation. The native mention mechanism remains unverified. Exact invocation UX, return-to-agent behavior and record-update confirmation are still implementation/product details to define. Only authorized conversation content is in scope. + +## Assumptions, evidence, and open questions + +The native mention mechanism remains unverified. Exact invocation UX, return-to-agent behavior and record-update confirmation are still implementation/product details to define. Only authorized conversation content is in scope. + +## Extra notes and follow-ups + +The linked-line follow-up holds remaining WhatsApp integration verification. These product questions stay in the active session. + +## History + +- 2026-10-15T14:38:24Z — Prepared the round 8 question after preserving the round 7 reply and checking relevant official documentation. + +- 2026-10-15T14:45:47Z — Saved round 8 reply and confirmed its explicit scope. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D025-remembered-language-preference-owner.md b/.planning/decisions/20261015T085738Z-3/D025-remembered-language-preference-owner.md new file mode 100644 index 0000000..67af061 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D025-remembered-language-preference-owner.md @@ -0,0 +1,86 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D025", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Whose language preference?", + "status": "confirmed", + "round": 8, + "created_at": "2026-10-15T14:38:24Z", + "updated_at": "2026-10-15T14:45:47Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D016-booking-for-someone-else.md", + ".planning/decisions/20261015T085738Z-3/D020-patient-conversation-languages.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Language preferences", + "Communication contacts", + "Patient profiles" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D016-booking-for-someone-else.md", + ".planning/decisions/20261015T085738Z-3/D020-patient-conversation-languages.md" + ], + "reply_recorded_at": "2026-10-15T14:45:47Z" +} +--- + +# Context — why ask this? + +Contacts can book for other patients and language preference is remembered. The preference owner must be explicit to avoid changing a represented patient's preferences based on another person's messages. + +## Predecessor decisions + +[D016](D016-booking-for-someone-else.md); [D020](D020-patient-conversation-languages.md). Their accepted outcomes are prerequisites; no other round 8 outcome is assumed. Where groups are relevant, see [the feasibility note](whatsapp-group-feasibility.md). + +## Question + +Q32 — Whose language preference?: Should the remembered chat language belong to the person/contact speaking, so a parent chatting in French does not automatically overwrite a child's patient-profile language? + +## Recommendation and alternatives + +Yes. Keep staff-account and communication-contact preferences separate from the patient being booked, and honor explicit language-change requests. + +The current decision records the user reply below. Earlier recommendations are not automatically accepted where the user supplied a different configuration. + +## User reply — original words + +Round 8 reply, recorded 2026-10-15T14:45:47Z; original message timestamp unavailable: + +> q32: yeah + +## Interpretation + +The user accepts remembering language for the person/contact speaking, separately from a represented patient. Staff-account preferences and external communication-contact preferences are distinct; explicit changes are honored. + +## Decision and rationale + +Confirmed: remembered chat language belongs to the speaking user/contact, not automatically to the patient they are booking for. A parent's language does not overwrite a child's patient-profile language. + +## Consequences and affected components + +Confirmed: remembered chat language belongs to the speaking user/contact, not automatically to the patient they are booking for. A parent's language does not overwrite a child's patient-profile language. Handling a phone/line shared by multiple speakers, mixed-language messages and identity changes remains open; the accepted distinction does not solve identifying each physical speaker. + +## Assumptions, evidence, and open questions + +Handling a phone/line shared by multiple speakers, mixed-language messages and identity changes remains open; the accepted distinction does not solve identifying each physical speaker. + +## Extra notes and follow-ups + +The linked-line follow-up holds remaining WhatsApp integration verification. These product questions stay in the active session. + +## History + +- 2026-10-15T14:38:24Z — Prepared the round 8 question after preserving the round 7 reply and checking relevant official documentation. + +- 2026-10-15T14:45:47Z — Saved round 8 reply and confirmed its explicit scope. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D026-initial-availability-source.md b/.planning/decisions/20261015T085738Z-3/D026-initial-availability-source.md new file mode 100644 index 0000000..514f387 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D026-initial-availability-source.md @@ -0,0 +1,89 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D026", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Where does availability come from?", + "status": "confirmed", + "round": 9, + "created_at": "2026-10-15T14:45:47Z", + "updated_at": "2026-10-15T14:52:33Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md", + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md", + ".planning/decisions/20261015T085738Z-3/D018-linked-line-doctor-routing.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Availability setup", + "Doctor calendar", + "Booking source of truth" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md", + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md", + ".planning/decisions/20261015T085738Z-3/D018-linked-line-doctor-routing.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T14:52:33Z" +} +--- + +# Context — why ask this? + +Reliable conversational booking needs an operational source of availability. The initial product scope has not selected whether an external calendar is a launch requirement. This is a workflow decision, not a technology stack choice. + +## Predecessor decisions + +[D002](D002-anchor-problem.md); [D009](D009-routine-booking-authority.md); [D018](D018-linked-line-doctor-routing.md). Accepted outcomes provide the prerequisites; no other round 9 answer is assumed. + +## Question + +Q33 — Where does availability come from?: For the first version, should doctors/staff manage working hours, breaks, blocked time and appointments directly in Medora, or must an existing external calendar also stay synchronized from day one? + +## Recommendation and alternatives + +Use Medora as the scheduling source for the first increment, with authorized staff maintaining real availability there. Preserve external calendar synchronization in the feature register for later. + +The user accepted the current choice in the recorded reply. Details not supplied remain explicitly open. + +## User reply — original words + +Round 9 reply, recorded 2026-10-15T14:52:33Z; original message timestamp unavailable: + +> q33: yeah for starter + +## Interpretation + +The user accepts Medora as the initial scheduling source, with doctors/authorized staff managing real working hours, breaks, blocks and appointments there. External calendar synchronization remains planned for later rather than required at launch. + +## Decision and rationale + +Confirmed initial workflow: manage the authoritative schedule directly in Medora. External calendar integrations stay in the feature register for a future increment. + +## Consequences and affected components + +Confirmed initial workflow: manage the authoritative schedule directly in Medora. External calendar integrations stay in the feature register for a future increment. Minimum setup, appointment-type durations, doctor-specific working hours, migration of existing commitments and operational schedule maintenance remain to be specified. No external calendar provider or stack is selected. + +## Assumptions, evidence, and open questions + +Minimum setup, appointment-type durations, doctor-specific working hours, migration of existing commitments and operational schedule maintenance remain to be specified. No external calendar provider or stack is selected. + +## Extra notes and follow-ups + +The wider feature register remains intact. No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T14:45:47Z — Prepared the round 9 question from confirmed prerequisites. + +- 2026-10-15T14:52:33Z — Saved round 9 reply and confirmed the choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D027-approved-practice-information.md b/.planning/decisions/20261015T085738Z-3/D027-approved-practice-information.md new file mode 100644 index 0000000..5815c3c --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D027-approved-practice-information.md @@ -0,0 +1,87 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D027", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Questions beyond appointments", + "status": "confirmed", + "round": 9, + "created_at": "2026-10-15T14:45:47Z", + "updated_at": "2026-10-15T14:52:33Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md", + ".planning/decisions/20261015T085738Z-3/D023-handoff-staff-assignment.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Practice information", + "Patient questions", + "Staff handoff" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md", + ".planning/decisions/20261015T085738Z-3/D023-handoff-staff-assignment.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T14:52:33Z" +} +--- + +# Context — why ask this? + +The user described appointment questions and other matters in WhatsApp. The safe and useful initial practical-information scope should be explicit, with an authoritative practice source. + +## Predecessor decisions + +[D006](D006-booking-entry.md); [D023](D023-handoff-staff-assignment.md). Accepted outcomes provide the prerequisites; no other round 9 answer is assumed. + +## Question + +Q34 — Questions beyond appointments: Should the agent answer practical questions such as opening hours, address, consultation fees and practice-approved preparation instructions, using information maintained by the practice? + +## Recommendation and alternatives + +Yes. Answer from approved practice information; if it is missing or uncertain, ask the configured staff member. Keep the existing boundaries against diagnosis or prescribing. + +The user accepted the current choice in the recorded reply. Details not supplied remain explicitly open. + +## User reply — original words + +Round 9 reply, recorded 2026-10-15T14:52:33Z; original message timestamp unavailable: + +> q34: yes, good idea so they avoid embarassement! + +## Interpretation + +The user accepts practical practice-information answers and explicitly identifies reduced embarrassment as a benefit. This supports discreet, approachable answers to questions such as fees and preparation. No actual patient-study finding is claimed; this rationale comes from the product owner. + +## Decision and rationale + +Confirmed: answer practical questions from information maintained/approved by the practice; route missing or uncertain information to configured staff. The user's stated reason is helping patients avoid embarrassment. + +## Consequences and affected components + +Confirmed: answer practical questions from information maintained/approved by the practice; route missing or uncertain information to configured staff. The user's stated reason is helping patients avoid embarrassment. Practice information ownership, approval/update flow, missing/outdated information handling and the exact set of launch questions remain to be defined. Clinical diagnosis/prescribing boundaries remain unchanged. + +## Assumptions, evidence, and open questions + +Practice information ownership, approval/update flow, missing/outdated information handling and the exact set of launch questions remain to be defined. Clinical diagnosis/prescribing boundaries remain unchanged. + +## Extra notes and follow-ups + +The wider feature register remains intact. No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T14:45:47Z — Prepared the round 9 question from confirmed prerequisites. + +- 2026-10-15T14:52:33Z — Saved round 9 reply and confirmed the choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D028-notification-failure-after-confirmation.md b/.planning/decisions/20261015T085738Z-3/D028-notification-failure-after-confirmation.md new file mode 100644 index 0000000..75e4f77 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D028-notification-failure-after-confirmation.md @@ -0,0 +1,89 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D028", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "A confirmation message fails", + "status": "confirmed", + "round": 9, + "created_at": "2026-10-15T14:45:47Z", + "updated_at": "2026-10-15T14:52:33Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md", + ".planning/decisions/20261015T085738Z-3/D013-replacement-slot-agreement.md", + ".planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Appointment state", + "Notification delivery", + "Staff attention queue" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md", + ".planning/decisions/20261015T085738Z-3/D013-replacement-slot-agreement.md", + ".planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T14:52:33Z" +} +--- + +# Context — why ask this? + +Successful appointment operations and successful patient notification are different outcomes. The user requires notifications but has not chosen what a delivery failure does to the booking. + +## Predecessor decisions + +[D009](D009-routine-booking-authority.md); [D013](D013-replacement-slot-agreement.md); [D015](D015-practice-and-doctor-routing.md). Accepted outcomes provide the prerequisites; no other round 9 answer is assumed. + +## Question + +Q35 — A confirmation message fails: If staff confirms an appointment but the WhatsApp notification cannot be delivered, should the appointment stay confirmed while staff see the delivery failure and Medora retries? + +## Recommendation and alternatives + +Yes. Track appointment status and message delivery separately. Alert staff, retry according to policy, and do not silently cancel or claim the patient was informed. + +The user accepted the current choice in the recorded reply. Details not supplied remain explicitly open. + +## User reply — original words + +Round 9 reply, recorded 2026-10-15T14:52:33Z; original message timestamp unavailable: + +> q35: ok + +## Interpretation + +The user accepts keeping the successfully confirmed appointment while tracking a failed WhatsApp notification separately, notifying staff and retrying under policy. Failure to deliver does not silently undo the booking. + +## Decision and rationale + +Confirmed: appointment state and notification-delivery state are separate; preserve the confirmed booking, surface failed delivery to staff, and retry according to practice/system policy without claiming the patient was informed. + +## Consequences and affected components + +Confirmed: appointment state and notification-delivery state are separate; preserve the confirmed booking, surface failed delivery to staff, and retry according to practice/system policy without claiming the patient was informed. Retry timing, limits, escalation, alternative contact methods and what staff do if delivery never succeeds remain open. No guaranteed delivery or automatic alternate-channel consent is inferred. + +## Assumptions, evidence, and open questions + +Retry timing, limits, escalation, alternative contact methods and what staff do if delivery never succeeds remain open. No guaranteed delivery or automatic alternate-channel consent is inferred. + +## Extra notes and follow-ups + +The wider feature register remains intact. No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T14:45:47Z — Prepared the round 9 question from confirmed prerequisites. + +- 2026-10-15T14:52:33Z — Saved round 9 reply and confirmed the choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D029-first-contact-existing-record-access.md b/.planning/decisions/20261015T085738Z-3/D029-first-contact-existing-record-access.md new file mode 100644 index 0000000..cbff58c --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D029-first-contact-existing-record-access.md @@ -0,0 +1,87 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D029", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Access to existing patient information", + "status": "confirmed", + "round": 9, + "created_at": "2026-10-15T14:45:47Z", + "updated_at": "2026-10-15T14:52:33Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D016-booking-for-someone-else.md", + ".planning/decisions/20261015T085738Z-3/D019-contact-with-multiple-patient-profiles.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Patient identity", + "Representative access", + "Appointment queries and changes" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D016-booking-for-someone-else.md", + ".planning/decisions/20261015T085738Z-3/D019-contact-with-multiple-patient-profiles.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T14:52:33Z" +} +--- + +# Context — why ask this? + +The user accepts caregiver bookings and reuse of verified relationships. The first-time/uncertain relationship boundary must prevent someone from gaining records merely by supplying a name or phone number. + +## Predecessor decisions + +[D016](D016-booking-for-someone-else.md); [D019](D019-contact-with-multiple-patient-profiles.md). Accepted outcomes provide the prerequisites; no other round 9 answer is assumed. + +## Question + +Q36 — Access to existing patient information: For an unverified contact asking about an existing patient, should staff verify the contact-patient relationship before Medora reveals past appointments or permits changes to an existing booking? + +## Recommendation and alternatives + +Yes. A new appointment request may still be taken for staff review, but existing private information and booking changes require the approved identity/authorization check. + +The user accepted the current choice in the recorded reply. Details not supplied remain explicitly open. + +## User reply — original words + +Round 9 reply, recorded 2026-10-15T14:52:33Z; original message timestamp unavailable: + +> q36: ok + +## Interpretation + +The user accepts staff verification of an uncertain/new contact-patient relationship before revealing existing appointment information or permitting changes to an existing booking. A new request can still enter review without disclosing old records. + +## Decision and rationale + +Confirmed: existing private information and booking changes require the approved verification/authorization check; staff verify unverified contact-patient relationships. New appointment requests may be collected for staff review. + +## Consequences and affected components + +Confirmed: existing private information and booking changes require the approved verification/authorization check; staff verify unverified contact-patient relationships. New appointment requests may be collected for staff review. Exact evidence/checks, caregiver authorization, verification recording, account/number changes, staff workflow and re-verification triggers remain detailed product decisions. + +## Assumptions, evidence, and open questions + +Exact evidence/checks, caregiver authorization, verification recording, account/number changes, staff workflow and re-verification triggers remain detailed product decisions. + +## Extra notes and follow-ups + +The wider feature register remains intact. No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T14:45:47Z — Prepared the round 9 question from confirmed prerequisites. + +- 2026-10-15T14:52:33Z — Saved round 9 reply and confirmed the choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D030-staff-daily-workspace.md b/.planning/decisions/20261015T085738Z-3/D030-staff-daily-workspace.md new file mode 100644 index 0000000..bb7228b --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D030-staff-daily-workspace.md @@ -0,0 +1,90 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D030", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "The staff workspace", + "status": "confirmed", + "round": 10, + "created_at": "2026-10-15T14:52:33Z", + "updated_at": "2026-10-15T15:38:29Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md", + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md", + ".planning/decisions/20261015T085738Z-3/D026-initial-availability-source.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Staff interface", + "Calendar", + "Request review", + "Patient profiles" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md", + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md", + ".planning/decisions/20261015T085738Z-3/D026-initial-availability-source.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T15:38:29Z" +} +--- + +# Context — why ask this? + +The patient experience is fully conversational and staff use private management chat. The initial staff workspace still needs a decision about direct visual access to operational records. + +## Predecessor decisions + +[D007](D007-basic-patient-profile.md); [D009](D009-routine-booking-authority.md); [D026](D026-initial-availability-source.md). Accepted outcomes supply the prerequisites; no answer to another round 10 question is assumed. + +## Question + +Q37 — The staff workspace: Alongside private chat, should doctors and receptionists have a compact calendar, a queue of requests awaiting review, and patient profile cards, so they can inspect information without asking the agent every time? + +## Recommendation and alternatives + +Yes. Keep chat central, with direct views of the schedule, review queue and profiles. Permissions determine what each staff user can see and change. + +The current decision below distinguishes the accepted reply from tentative/unresolved details; earlier recommendation wording is historical. + +## User reply — original words + +Round 10 reply, recorded 2026-10-15T15:38:29Z; original message timestamp unavailable: + +> q37: yes, its a fully functional platform, enhanced with integrated AI agents + +## Interpretation + +The user explicitly confirms that Medora is a functional practice-management platform enhanced with integrated AI agents. Staff must have direct operational interfaces for calendars, review queues and patient profiles as well as private assistant conversations. The earlier recommendation to keep chat central does not justify reducing the platform to a chatbot. The patient booking journey remains WhatsApp conversational. + +## Decision and rationale + +Confirmed: a functional staff-facing platform plus integrated agents, including direct schedule, request-review and profile access according to permissions. Incremental delivery still applies; this is not authorization to implement the entire long-term roadmap at once. + +## Consequences and affected components + +Confirmed: a functional staff-facing platform plus integrated agents, including direct schedule, request-review and profile access according to permissions. Incremental delivery still applies; this is not authorization to implement the entire long-term roadmap at once. Detailed interaction design, navigation and which staff actions need additional confirmation remain to be designed. No separate patient booking UI is introduced by this clarification. + +## Assumptions, evidence, and open questions + +Detailed interaction design, navigation and which staff actions need additional confirmation remain to be designed. No separate patient booking UI is introduced by this clarification. + +## Extra notes and follow-ups + +The complete vision stays registered. No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T14:52:33Z — Prepared the round 10 question from accepted prerequisites. + +- 2026-10-15T15:38:29Z — Saved round 10 reply; status confirmed. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D031-practice-setup-before-activation.md b/.planning/decisions/20261015T085738Z-3/D031-practice-setup-before-activation.md new file mode 100644 index 0000000..84c7aa9 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D031-practice-setup-before-activation.md @@ -0,0 +1,107 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D031", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Practice setup", + "status": "confirmed", + "round": 10, + "created_at": "2026-10-15T14:52:33Z", + "updated_at": "2026-10-15T15:44:38Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md", + ".planning/decisions/20261015T085738Z-3/D023-handoff-staff-assignment.md", + ".planning/decisions/20261015T085738Z-3/D026-initial-availability-source.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Practice onboarding", + "Booking configuration", + "Activation readiness" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md", + ".planning/decisions/20261015T085738Z-3/D023-handoff-staff-assignment.md", + ".planning/decisions/20261015T085738Z-3/D026-initial-availability-source.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T15:44:38Z", + "rounds": [ + 10, + 11 + ] +} +--- + +# Context — why ask this? + +Medora is now the initial schedule source and requires a linked communication line. The product needs a clear path from an empty practice to a working booking assistant. + +## Predecessor decisions + +[D015](D015-practice-and-doctor-routing.md); [D023](D023-handoff-staff-assignment.md); [D026](D026-initial-availability-source.md). Accepted outcomes supply the prerequisites; no answer to another round 10 question is assumed. + +## Question + +Q38 — Practice setup: Should a practice configure its doctors, availability, appointment durations, linked WhatsApp line and default staff member, then complete a test booking before activating patient-facing booking? + +### Round 11 clarification — Q41 — Lighter setup + +Would you prefer requiring only the essential booking configuration before activation, while making a test booking optional rather than a mandatory step? + +## Recommendation and alternatives + +Yes. Allow setup to be saved as a draft and clearly show what is missing before activation. Use synthetic information for the test booking. + +The current decision below distinguishes the accepted reply from tentative/unresolved details; earlier recommendation wording is historical. + +Round 11 recommendation: Yes: require a usable schedule, appointment durations, line routing and responsible staff; offer a guided test without forcing it. Let setup be saved and resumed. + +Q41 was answered; the current choice below replaces the earlier tentative setup position. + +## User reply — original words + +Round 10 reply, recorded 2026-10-15T15:38:29Z; original message timestamp unavailable: + +> q38: hmm ok ? + +Round 11 reply, recorded 2026-10-15T15:44:38Z; original message timestamp unavailable: + +> q41: ok + +## Interpretation + +The user accepts essential booking configuration before activation, an optional rather than mandatory guided test booking, and save/resume setup. This resolves the earlier tentative Q38 reply. + +## Decision and rationale + +Confirmed: require a usable schedule, appointment durations, line routing and responsible staff for patient-facing booking; offer an optional guided test and allow draft setup to be resumed. + +## Consequences and affected components + +Confirmed: require a usable schedule, appointment durations, line routing and responsible staff for patient-facing booking; offer an optional guided test and allow draft setup to be resumed. Exact setup screens and validation details remain open. No compulsory test-booking gate or provider-specific onboarding flow is introduced. + +## Assumptions, evidence, and open questions + +Exact setup screens and validation details remain open. No compulsory test-booking gate or provider-specific onboarding flow is introduced. + +## Extra notes and follow-ups + +The complete vision stays registered. No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T14:52:33Z — Prepared the round 10 question from accepted prerequisites. + +- 2026-10-15T15:38:29Z — Saved round 10 reply; status needs-clarification. Prior interpretation: Pending. Prior decision: Pending. + +- 2026-10-15T15:44:38Z — Saved round 11 reply and confirmed the explicit choice. Prior interpretation: The user expresses tentative acceptance or uncertainty about setup before activation. Do not treat this as unambiguous approval of a mandatory test booking or a rigid setup wizard. Clarify a lighter required-configuration/optional-test approach. Prior decision: Tentative only: practice setup is being discussed. The mandatory activation checklist and test-booking gate are not confirmed. Q41 will clarify. diff --git a/.planning/decisions/20261015T085738Z-3/D032-first-increment-appointment-lifecycle.md b/.planning/decisions/20261015T085738Z-3/D032-first-increment-appointment-lifecycle.md new file mode 100644 index 0000000..7cd5b2f --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D032-first-increment-appointment-lifecycle.md @@ -0,0 +1,92 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D032", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Changes and cancellations in beta", + "status": "confirmed", + "round": 10, + "created_at": "2026-10-15T14:52:33Z", + "updated_at": "2026-10-15T15:38:29Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md", + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md", + ".planning/decisions/20261015T085738Z-3/D013-replacement-slot-agreement.md", + ".planning/decisions/20261015T085738Z-3/D029-first-contact-existing-record-access.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "WhatsApp appointment management", + "Cancellation", + "Rescheduling", + "Beta scope" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md", + ".planning/decisions/20261015T085738Z-3/D006-booking-entry.md", + ".planning/decisions/20261015T085738Z-3/D013-replacement-slot-agreement.md", + ".planning/decisions/20261015T085738Z-3/D029-first-contact-existing-record-access.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T15:38:29Z" +} +--- + +# Context — why ask this? + +The initial increment is basic booking and profiling. The user accepted cancellation when a staff-proposed replacement does not fit, but ordinary patient-initiated cancellation/rescheduling release scope is not yet explicit. + +## Predecessor decisions + +[D002](D002-anchor-problem.md); [D006](D006-booking-entry.md); [D013](D013-replacement-slot-agreement.md); [D029](D029-first-contact-existing-record-access.md). Accepted outcomes supply the prerequisites; no answer to another round 10 question is assumed. + +## Question + +Q39 — Changes and cancellations in beta: Should the first beta let patients request cancellations and rescheduling through the same WhatsApp conversation, or should it initially handle new bookings while staff handle later changes? + +## Recommendation and alternatives + +Include basic cancellation and rescheduling requests in the initial booking workflow. Keep the accepted identity, staff-review and patient-agreement rules; defer advanced schedule optimization and waiting lists. + +The current decision below distinguishes the accepted reply from tentative/unresolved details; earlier recommendation wording is historical. + +## User reply — original words + +Round 10 reply, recorded 2026-10-15T15:38:29Z; original message timestamp unavailable: + +> q39: ok + +## Interpretation + +The user accepts basic cancellation and rescheduling requests through the same WhatsApp conversation in the initial beta, preserving the accepted verification, staff-review and replacement-agreement rules. Advanced optimization and waiting-list behavior remain later work. + +## Decision and rationale + +Confirmed: initial beta includes basic booking, cancellation/rescheduling requests and profiling. Exact cancellation execution/approval and ordinary practice-policy handling still require clarification. + +## Consequences and affected components + +Confirmed: initial beta includes basic booking, cancellation/rescheduling requests and profiling. Exact cancellation execution/approval and ordinary practice-policy handling still require clarification. Whether a verified cancellation is immediate or staff-approved, how an existing appointment is kept during a rescheduling request, and policy exception handling remain open. No fee, notice period, wait-list automation or auto-rescheduling is inferred. + +## Assumptions, evidence, and open questions + +Whether a verified cancellation is immediate or staff-approved, how an existing appointment is kept during a rescheduling request, and policy exception handling remain open. No fee, notice period, wait-list automation or auto-rescheduling is inferred. + +## Extra notes and follow-ups + +The complete vision stays registered. No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T14:52:33Z — Prepared the round 10 question from accepted prerequisites. + +- 2026-10-15T15:38:29Z — Saved round 10 reply; status confirmed. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D033-intake-template-and-profile-review.md b/.planning/decisions/20261015T085738Z-3/D033-intake-template-and-profile-review.md new file mode 100644 index 0000000..832d464 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D033-intake-template-and-profile-review.md @@ -0,0 +1,90 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D033", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Who controls intake?", + "status": "confirmed", + "round": 10, + "created_at": "2026-10-15T14:52:33Z", + "updated_at": "2026-10-15T15:38:29Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md", + ".planning/decisions/20261015T085738Z-3/D017-optional-conversational-intake.md", + ".planning/decisions/20261015T085738Z-3/D027-approved-practice-information.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Intake templates", + "Profile preparation", + "Information provenance", + "Staff correction" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md", + ".planning/decisions/20261015T085738Z-3/D017-optional-conversational-intake.md", + ".planning/decisions/20261015T085738Z-3/D027-approved-practice-information.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T15:38:29Z" +} +--- + +# Context — why ask this? + +Basic profiles and optional conversational intake are accepted. The first increment needs an explicit practice ownership and review workflow for the information it collects and presents. + +## Predecessor decisions + +[D007](D007-basic-patient-profile.md); [D017](D017-optional-conversational-intake.md); [D027](D027-approved-practice-information.md). Accepted outcomes supply the prerequisites; no answer to another round 10 question is assumed. + +## Question + +Q40 — Who controls intake?: Should doctors choose or approve the short intake questions for their appointment types, with Medora organizing the answers into a source-labelled profile and allowing authorized staff to correct it? + +## Recommendation and alternatives + +Yes. Use doctor-approved questions; keep patient statements, staff corrections and AI summaries distinguishable. Show unanswered questions and contradictions rather than filling gaps. + +The current decision below distinguishes the accepted reply from tentative/unresolved details; earlier recommendation wording is historical. + +## User reply — original words + +Round 10 reply, recorded 2026-10-15T15:38:29Z; original message timestamp unavailable: + +> q40: ok + +## Interpretation + +The user accepts doctors choosing/approving short intake questions by appointment type, organizing replies into source-labelled profiles, and authorized staff corrections while preserving provenance. + +## Decision and rationale + +Confirmed: doctor-owned/approved intake templates, source-labelled patient information, authorized correction, and explicit missing/contradictory information. Staff corrections and AI summaries remain distinguishable from the original patient statements. + +## Consequences and affected components + +Confirmed: doctor-owned/approved intake templates, source-labelled patient information, authorized correction, and explicit missing/contradictory information. Staff corrections and AI summaries remain distinguishable from the original patient statements. Exact template fields, versioning, correction permissions, review presentation and initial questionnaire limits remain implementation/product details. No clinician-authored diagnosis or prescription feature is added. + +## Assumptions, evidence, and open questions + +Exact template fields, versioning, correction permissions, review presentation and initial questionnaire limits remain implementation/product details. No clinician-authored diagnosis or prescription feature is added. + +## Extra notes and follow-ups + +The complete vision stays registered. No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T14:52:33Z — Prepared the round 10 question from accepted prerequisites. + +- 2026-10-15T15:38:29Z — Saved round 10 reply; status confirmed. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D034-practice-configuration-ownership.md b/.planning/decisions/20261015T085738Z-3/D034-practice-configuration-ownership.md new file mode 100644 index 0000000..9054ce3 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D034-practice-configuration-ownership.md @@ -0,0 +1,97 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D034", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Who manages the practice?", + "status": "confirmed", + "round": 11, + "created_at": "2026-10-15T15:38:29Z", + "updated_at": "2026-10-15T15:44:38Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D011-staff-approval-permissions.md", + ".planning/decisions/20261015T085738Z-3/D023-handoff-staff-assignment.md", + ".planning/decisions/20261015T085738Z-3/D030-staff-daily-workspace.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Practice ownership", + "Staff membership", + "Permissions", + "Connected lines" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D011-staff-approval-permissions.md", + ".planning/decisions/20261015T085738Z-3/D023-handoff-staff-assignment.md", + ".planning/decisions/20261015T085738Z-3/D030-staff-daily-workspace.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T15:44:38Z", + "amends": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md" + ] +} +--- + +# Context — why ask this? + +The user confirms a functional platform with staff and connected lines. Authority to configure its people and communication boundaries is not yet assigned. + +## Predecessor decisions + +[D001](D001-first-practice.md); [D011](D011-staff-approval-permissions.md); [D023](D023-handoff-staff-assignment.md); [D030](D030-staff-daily-workspace.md). Accepted outcomes provide the prerequisites; no other round 11 answer is assumed. + +## Question + +Q42 — Who manages the practice?: Who should control staff invitations, permissions and connected lines: a designated practice owner, or every doctor? + +## Recommendation and alternatives + +Use a designated practice-owner capability, with delegated permissions. Keep the existing Doctor/Receptionist/Patient roles; ownership is a responsibility within the practice, not a fourth patient-facing role. Doctors retain approval of clinical intake content. + +The current choice below records the user reply; earlier recommendations remain historical. + +## User reply — original words + + + +Round 11 reply, recorded 2026-10-15T15:44:38Z; original message timestamp unavailable: + +> q42: an owner (admin account) + +## Interpretation + +The user explicitly selects an Owner/Admin account to manage the practice. This updates the earlier three-operational-role framing and does not merely endorse the assistant's suggested ownership capability without an admin designation. In context, this is a practice owner/admin, not a global platform superadministrator. + +## Decision and rationale + +Confirmed: an explicit practice Owner/Admin account controls practice administration such as staff invitations, permissions and connected lines. Doctor, Receptionist and Patient remain operational roles. The user did not specify whether one person/account can combine administrative and clinical roles. + +## Consequences and affected components + +Confirmed: an explicit practice Owner/Admin account controls practice administration such as staff invitations, permissions and connected lines. Doctor, Receptionist and Patient remain operational roles. The user did not specify whether one person/account can combine administrative and clinical roles. Fine-grained admin permissions, delegation and role combinations remain open. Administrative control does not automatically settle clinical-record visibility; existing least-privilege and doctor clinical-approval boundaries remain. D001 is partially amended only as to the role set. + +## Assumptions, evidence, and open questions + +Fine-grained admin permissions, delegation and role combinations remain open. Administrative control does not automatically settle clinical-record visibility; existing least-privilege and doctor clinical-approval boundaries remain. D001 is partially amended only as to the role set. + +## Extra notes and follow-ups + +No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T15:38:29Z — Prepared the round 11 question from confirmed prerequisites. + +- 2026-10-15T15:44:38Z — Saved round 11 reply and confirmed the explicit choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D035-verified-patient-cancellation.md b/.planning/decisions/20261015T085738Z-3/D035-verified-patient-cancellation.md new file mode 100644 index 0000000..a322715 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D035-verified-patient-cancellation.md @@ -0,0 +1,92 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D035", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Patient cancellation", + "status": "confirmed", + "round": 11, + "created_at": "2026-10-15T15:38:29Z", + "updated_at": "2026-10-15T15:44:38Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D013-replacement-slot-agreement.md", + ".planning/decisions/20261015T085738Z-3/D029-first-contact-existing-record-access.md", + ".planning/decisions/20261015T085738Z-3/D032-first-increment-appointment-lifecycle.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Cancellation", + "Practice policies", + "Slot availability", + "Patient confirmation" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D013-replacement-slot-agreement.md", + ".planning/decisions/20261015T085738Z-3/D029-first-contact-existing-record-access.md", + ".planning/decisions/20261015T085738Z-3/D032-first-increment-appointment-lifecycle.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T15:44:38Z" +} +--- + +# Context — why ask this? + +Cancellation requests are now in beta scope. Staff-reviewed booking does not automatically settle whether the patient can immediately release their own appointment. + +## Predecessor decisions + +[D013](D013-replacement-slot-agreement.md); [D029](D029-first-contact-existing-record-access.md); [D032](D032-first-increment-appointment-lifecycle.md). Accepted outcomes provide the prerequisites; no other round 11 answer is assumed. + +## Question + +Q43 — Patient cancellation: When a verified patient clearly asks to cancel, should Medora execute it immediately within the practice policy, or always wait for staff approval? + +## Recommendation and alternatives + +Cancel immediately when the configured policy allows it, notify staff and release the slot. Route policy exceptions to staff; report completion only after cancellation succeeds. + +The current choice below records the user reply; earlier recommendations remain historical. + +## User reply — original words + + + +Round 11 reply, recorded 2026-10-15T15:44:38Z; original message timestamp unavailable: + +> q43: yeah immediatly and staff gets notified + +## Interpretation + +The user explicitly wants verified patient cancellation executed immediately, with staff notification, rather than requiring a fresh staff approval. Release the slot only through a successful authorized cancellation and communicate the actual result. + +## Decision and rationale + +Confirmed: verified patients can cancel immediately; execute the cancellation, release the slot and notify staff. Do not add ordinary staff-approval waiting to this flow. + +## Consequences and affected components + +Confirmed: verified patients can cancel immediately; execute the cancellation, release the slot and notify staff. Do not add ordinary staff-approval waiting to this flow. Cancellation fees/financial consequences, verification evidence, policy messaging and exceptional failed-operation handling remain unspecified. No monetary policy is inferred from immediate cancellation. + +## Assumptions, evidence, and open questions + +Cancellation fees/financial consequences, verification evidence, policy messaging and exceptional failed-operation handling remain unspecified. No monetary policy is inferred from immediate cancellation. + +## Extra notes and follow-ups + +No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T15:38:29Z — Prepared the round 11 question from confirmed prerequisites. + +- 2026-10-15T15:44:38Z — Saved round 11 reply and confirmed the explicit choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D036-default-staff-unavailable.md b/.planning/decisions/20261015T085738Z-3/D036-default-staff-unavailable.md new file mode 100644 index 0000000..4e590f0 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D036-default-staff-unavailable.md @@ -0,0 +1,94 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D036", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Default staff unavailable", + "status": "confirmed", + "round": 11, + "created_at": "2026-10-15T15:38:29Z", + "updated_at": "2026-10-15T15:44:38Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D011-staff-approval-permissions.md", + ".planning/decisions/20261015T085738Z-3/D014-review-deadline-outside-working-hours.md", + ".planning/decisions/20261015T085738Z-3/D023-handoff-staff-assignment.md", + ".planning/decisions/20261015T085738Z-3/D030-staff-daily-workspace.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Handoff assignment", + "Staff attention queue", + "Backup coverage", + "Patient expectations" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D011-staff-approval-permissions.md", + ".planning/decisions/20261015T085738Z-3/D014-review-deadline-outside-working-hours.md", + ".planning/decisions/20261015T085738Z-3/D023-handoff-staff-assignment.md", + ".planning/decisions/20261015T085738Z-3/D030-staff-daily-workspace.md", + "docs/product-vision.md" + ], + "reply_recorded_at": "2026-10-15T15:44:38Z" +} +--- + +# Context — why ask this? + +Human handoff targets a default staff member. The platform needs an explicit operational path when that person cannot respond. This is routine administrative handoff, not a replacement for urgent clinical escalation. + +## Predecessor decisions + +[D011](D011-staff-approval-permissions.md); [D014](D014-review-deadline-outside-working-hours.md); [D023](D023-handoff-staff-assignment.md); [D030](D030-staff-daily-workspace.md). Accepted outcomes provide the prerequisites; no other round 11 answer is assumed. + +## Question + +Q44 — Default staff unavailable: If the configured default staff member is unavailable, should the practice be able to name a backup, with unresolved handoffs kept visible in a shared authorized queue? + +## Recommendation and alternatives + +Yes. Notify the configured backup and keep the patient informed that a reply is pending. Do not imply that a human has responded or promise an unsupported response time. + +The current choice below records the user reply; earlier recommendations remain historical. + +## User reply — original words + + + +Round 11 reply, recorded 2026-10-15T15:44:38Z; original message timestamp unavailable: + +> q44: yeah + +## Interpretation + +The user accepts a configured backup for unavailable default staff and visibility of unresolved handoffs in a shared authorized queue, with honest pending-response communication. + +## Decision and rationale + +Confirmed: practices may configure backup staff; unresolved handoffs remain in an authorized shared queue, with backup notification and accurate patient status. + +## Consequences and affected components + +Confirmed: practices may configure backup staff; unresolved handoffs remain in an authorized shared queue, with backup notification and accurate patient status. Backup selection details, availability detection, reassignment and escalation timing remain open. No response-time guarantee or all-staff access to private chat is created. + +## Assumptions, evidence, and open questions + +Backup selection details, availability detection, reassignment and escalation timing remain open. No response-time guarantee or all-staff access to private chat is created. + +## Extra notes and follow-ups + +No unrelated follow-up introduced by this question. + +## History + +- 2026-10-15T15:38:29Z — Prepared the round 11 question from confirmed prerequisites. + +- 2026-10-15T15:44:38Z — Saved round 11 reply and confirmed the explicit choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D037-keep-original-during-rescheduling.md b/.planning/decisions/20261015T085738Z-3/D037-keep-original-during-rescheduling.md new file mode 100644 index 0000000..0db183b --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D037-keep-original-during-rescheduling.md @@ -0,0 +1,89 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D037", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "While rescheduling is pending", + "status": "confirmed", + "round": 12, + "created_at": "2026-10-15T15:44:38Z", + "updated_at": "2026-10-15T15:54:26Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md", + ".planning/decisions/20261015T085738Z-3/D013-replacement-slot-agreement.md", + ".planning/decisions/20261015T085738Z-3/D032-first-increment-appointment-lifecycle.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Rescheduling", + "Original booking", + "Provisional replacement", + "Patient agreement" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D009-routine-booking-authority.md", + ".planning/decisions/20261015T085738Z-3/D013-replacement-slot-agreement.md", + ".planning/decisions/20261015T085738Z-3/D032-first-increment-appointment-lifecycle.md" + ], + "reply_recorded_at": "2026-10-15T15:54:26Z" +} +--- + +# Context — why ask this? + +Basic rescheduling is in beta scope. Keeping or releasing the original while a replacement is pending is not yet settled and directly affects patient confidence and availability. + +## Predecessor decisions + +[D009](D009-routine-booking-authority.md); [D013](D013-replacement-slot-agreement.md); [D032](D032-first-increment-appointment-lifecycle.md). Accepted outcomes supply the prerequisites; no other round 12 answer is assumed. + +## Question + +Q45 — While rescheduling is pending: When a patient requests a different time, should the original appointment remain booked until the replacement is approved and accepted, unless the original has explicitly been cancelled or is no longer available? + +## Recommendation and alternatives + +Yes. Reserve the proposed replacement provisionally, then switch only after staff approval and patient agreement. Do not make a patient lose their existing booking just by asking about another time. + +The user accepted the scope choice below; detailed design remains in the linked follow-ups. + +## User reply — original words + +Round 12 reply, recorded 2026-10-15T15:54:26Z; original message timestamp unavailable: + +> q45: ok + +## Interpretation + +The user accepts preserving the original appointment while a patient-requested replacement is pending. Replacement approval/agreement is required before switching, except when the original has explicitly been cancelled or is no longer available. + +## Decision and rationale + +Confirmed: exploring/reserving another time does not by itself remove the original booking. Keep the original until the replacement is approved and accepted, unless its cancellation/unavailability is explicit; communicate that exception clearly. + +## Consequences and affected components + +Confirmed: exploring/reserving another time does not by itself remove the original booking. Keep the original until the replacement is approved and accepted, unless its cancellation/unavailability is explicit; communicate that exception clearly. Detailed replacement-offer expiry, hold limits, cutoffs and atomic transition/failure behavior go to the booking-policy follow-up. + +## Assumptions, evidence, and open questions + +Detailed replacement-offer expiry, hold limits, cutoffs and atomic transition/failure behavior go to the booking-policy follow-up. + +## Extra notes and follow-ups + +Pending design details are listed in [the scope review](scope-review.md). Proposed deferrals are not yet accepted. + +## History + +- 2026-10-15T15:44:38Z — Prepared this round 12 question after recording round 11. + +- 2026-10-15T15:54:26Z — Saved round 12 reply and confirmed the explicit choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D038-optional-group-release-timing.md b/.planning/decisions/20261015T085738Z-3/D038-optional-group-release-timing.md new file mode 100644 index 0000000..239bbdf --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D038-optional-group-release-timing.md @@ -0,0 +1,90 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D038", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Groups in the first beta", + "status": "confirmed", + "round": 12, + "created_at": "2026-10-15T15:44:38Z", + "updated_at": "2026-10-15T15:54:26Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md", + ".planning/decisions/20261015T085738Z-3/D005-release-readiness.md", + ".planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md", + ".planning/decisions/20261015T085738Z-3/D022-optional-patient-group-handoff.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Beta scope", + "Human handoff", + "Optional patient groups" + ], + "follow_ups": [], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md", + ".planning/decisions/20261015T085738Z-3/D005-release-readiness.md", + ".planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md", + ".planning/decisions/20261015T085738Z-3/D022-optional-patient-group-handoff.md" + ], + "reply_recorded_at": "2026-10-15T15:54:26Z" +} +--- + +# Context — why ask this? + +Optional groups are accepted, but their delivery timing remains unsettled and the official eligibility/invocation constraints have not been integration-tested. This is a scope decision rather than a provider/stack selection. + +## Predecessor decisions + +[D002](D002-anchor-problem.md); [D005](D005-release-readiness.md); [D021](D021-staff-takeover-of-patient-chat.md); [D022](D022-optional-patient-group-handoff.md). Accepted outcomes supply the prerequisites; no other round 12 answer is assumed. + +## Question + +Q46 — Groups in the first beta: Should the first beta require complete one-to-one human handoff, while optional WhatsApp groups can be added once account eligibility, invitations and agent invocation have been verified? + +## Recommendation and alternatives + +Yes. Make the core handoff complete first; keep optional groups registered without making unverified group support a blocker for every practice. + +The user accepted the scope choice below; detailed design remains in the linked follow-ups. + +## User reply — original words + +Round 12 reply, recorded 2026-10-15T15:54:26Z; original message timestamp unavailable: + +> q46: ok + +## Interpretation + +The user accepts complete one-to-one human handoff as the beta baseline, with optional patient groups added only after their eligibility, invitations and agent invocation have been verified. Group support is not a universal beta prerequisite. + +## Decision and rationale + +Confirmed: baseline beta handoff works through the existing patient chat; optional patient groups remain registered and depend on verified support. + +## Consequences and affected components + +Confirmed: baseline beta handoff works through the existing patient chat; optional patient groups remain registered and depend on verified support. No release date is assigned. Group lifecycle/product details go to communication follow-up; eligibility/tag delivery verification stays in the existing WhatsApp technical-research follow-up. + +## Assumptions, evidence, and open questions + +No release date is assigned. Group lifecycle/product details go to communication follow-up; eligibility/tag delivery verification stays in the existing WhatsApp technical-research follow-up. + +## Extra notes and follow-ups + +Pending design details are listed in [the scope review](scope-review.md). Proposed deferrals are not yet accepted. + +## History + +- 2026-10-15T15:44:38Z — Prepared this round 12 question after recording round 11. + +- 2026-10-15T15:54:26Z — Saved round 12 reply and confirmed the explicit choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md b/.planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md new file mode 100644 index 0000000..8b84b9d --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md @@ -0,0 +1,101 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D039", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Detailed design follow-ups", + "status": "confirmed", + "round": 12, + "created_at": "2026-10-15T15:44:38Z", + "updated_at": "2026-10-15T15:54:26Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D000-planning-memory-and-scope.md", + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md", + ".planning/decisions/20261015T085738Z-3/D030-staff-daily-workspace.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Planning scope", + "Feature acceptance", + "Detailed permissions", + "Operational policies" + ], + "follow_ups": [ + ".planning/follow-ups/20261015T155426Z-define-detailed-booking-policies/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-identity-permissions-and-sharing/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-handoff-and-notification-workflows/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-profile-fields-and-intake-details/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-beta-validation-and-release-gates/follow-up.md" + ], + "sources": [ + ".planning/decisions/20261015T085738Z-3/D000-planning-memory-and-scope.md", + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md", + ".planning/decisions/20261015T085738Z-3/D030-staff-daily-workspace.md" + ], + "reply_recorded_at": "2026-10-15T15:54:26Z" +} +--- + +# Context — why ask this? + +The product foundation is now extensively recorded. Detailed decisions remain, and the user requested durable follow-ups; explicit agreement is needed to defer them rather than silently treating the design as complete. + +## Predecessor decisions + +[D000](D000-planning-memory-and-scope.md); [D002](D002-anchor-problem.md); [D030](D030-staff-daily-workspace.md). Accepted outcomes supply the prerequisites; no other round 12 answer is assumed. + +## Question + +Q47 — Detailed design follow-ups: After these scope decisions, shall we capture exact policy values, verification evidence, permission details, group lifecycle, sharing revocation, retry/escalation rules and beta-readiness criteria as focused follow-ups, each resolved before its affected feature is implemented or used? + +## Recommendation and alternatives + +Yes. Preserve these open branches with context, dependencies and revisit triggers, then review the consolidated product understanding. Deferral must not be mistaken for implementation readiness. + +The user accepted the scope choice below; detailed design remains in the linked follow-ups. + +## User reply — original words + +Round 12 reply, recorded 2026-10-15T15:54:26Z; original message timestamp unavailable: + +> q47: ok + +## Interpretation + +The user explicitly accepts capturing the listed unresolved details as durable focused follow-ups, each resolved before its affected implementation or live use. This permits a bounded product-foundation review without silently declaring those detailed designs complete. + +## Decision and rationale + +Confirmed: defer exact policy values, verification evidence, detailed permissions, group lifecycle, sharing revocation, retry/escalation and beta-readiness definitions to linked follow-ups with context and revisit triggers. This is not permission to bypass them or start a technical stack discussion. + +## Consequences and affected components + +Confirmed: defer exact policy values, verification evidence, detailed permissions, group lifecycle, sharing revocation, retry/escalation and beta-readiness definitions to linked follow-ups with context and revisit triggers. This is not permission to bypass them or start a technical stack discussion. Session-level shared-understanding confirmation remains pending. The current reply agrees to the deferral plan, not an unseen final summary. + +## Assumptions, evidence, and open questions + +Session-level shared-understanding confirmation remains pending. The current reply agrees to the deferral plan, not an unseen final summary. + +## Extra notes and follow-ups + +The following user-approved focused work is now captured: + +- [20261015T155426Z-define-detailed-booking-policies](../../follow-ups/20261015T155426Z-define-detailed-booking-policies/follow-up.md) +- [20261015T155426Z-define-identity-permissions-and-sharing](../../follow-ups/20261015T155426Z-define-identity-permissions-and-sharing/follow-up.md) +- [20261015T155426Z-define-handoff-and-notification-workflows](../../follow-ups/20261015T155426Z-define-handoff-and-notification-workflows/follow-up.md) +- [20261015T155426Z-define-profile-fields-and-intake-details](../../follow-ups/20261015T155426Z-define-profile-fields-and-intake-details/follow-up.md) +- [20261015T155426Z-define-beta-validation-and-release-gates](../../follow-ups/20261015T155426Z-define-beta-validation-and-release-gates/follow-up.md) + +## History + +- 2026-10-15T15:44:38Z — Prepared this round 12 question after recording round 11. + +- 2026-10-15T15:54:26Z — Saved round 12 reply and confirmed the explicit choice. Prior interpretation: Pending. Prior decision: Pending. diff --git a/.planning/decisions/20261015T085738Z-3/D040-shared-understanding-confirmation.md b/.planning/decisions/20261015T085738Z-3/D040-shared-understanding-confirmation.md new file mode 100644 index 0000000..cffbd9e --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/D040-shared-understanding-confirmation.md @@ -0,0 +1,91 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3/D040", + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "title": "Shared understanding confirmation", + "status": "confirmed", + "round": 13, + "created_at": "2026-10-15T15:54:26Z", + "updated_at": "2026-10-15T15:57:45Z", + "asked_at": null, + "answered_at": null, + "confirmed_at": null, + "decision_owner": "user", + "recorded_by": "assistant", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "predecessors": [ + ".planning/decisions/20261015T085738Z-3/D037-keep-original-during-rescheduling.md", + ".planning/decisions/20261015T085738Z-3/D038-optional-group-release-timing.md", + ".planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md" + ], + "related_decisions": [], + "supersedes": [], + "superseded_by": [], + "affected_components": [ + "Product foundation", + "Session conclusion" + ], + "follow_ups": [ + ".planning/follow-ups/20261015T155426Z-define-detailed-booking-policies/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-identity-permissions-and-sharing/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-handoff-and-notification-workflows/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-profile-fields-and-intake-details/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-beta-validation-and-release-gates/follow-up.md" + ], + "sources": [ + ".planning/decisions/20261015T085738Z-3/scope-review.md" + ], + "confirmation_recorded_at": "2026-10-15T15:57:45Z" +} +--- + +# Context — why ask this? + +The independent product choices are confirmed or explicitly deferred. A concrete scope review and follow-up records now exist; the grilling skill and repository instructions require explicit shared-understanding confirmation before acting on the resulting design. + +## Predecessor decisions + +D037 preserves existing appointments during rescheduling; D038 stages optional groups after baseline handoff verification; D039 authorizes focused-detail deferrals. The complete session index and scope review link the rest. + +## Question + +Does this accurately capture our shared understanding, including the recorded follow-ups? + +Presented with the consolidated product summary and the linked scope review; the summary also stated that no technical stack had been selected. + +## Recommendation and alternatives + +Confirm if accurate, or state corrections to the consolidated scope. Confirmation records shared product understanding; it is not automatic authorization to choose a stack, deploy, merge or implement deferred decisions. + +## User reply — original words + +Final confirmation, recorded 2026-10-15T15:57:45Z. Source: the current conversation, user response immediately following the consolidated product summary. Original message timestamp/URL unavailable. + +> yes confirmed + +## Interpretation + +The user explicitly confirms the consolidated product understanding and the recorded focused follow-ups. This completes the foundational discovery session. It does not resolve the deferred details or request a technical-stack choice, application implementation, deployment, or automatic PR merge. + +## Decision and rationale + +Confirmed: the scope review is the agreed product foundation. All independent interview questions are confirmed or explicitly deferred; final shared-understanding confirmation is now recorded. The detailed follow-ups remain open prerequisites to affected work. + +## Consequences and affected components + +Mark the discovery session confirmed, retain all source replies/history and follow-up records, and publish the confirmation to the existing documentation PR for review. Implementation planning must read the confirmed scope and resolve relevant prerequisites. + +## Assumptions, evidence, and open questions + +No current question remains for this foundation session. Open detailed design and feasibility work stays in the follow-up index. Timestamp metadata records when confirmation was saved, not an inferred original user-message send time. + +## Extra notes and follow-ups + +See the scope review and linked follow-up records. + +## History + +- 2026-10-15T15:54:26Z — Prepared final shared-understanding question after saving round 12 and creating the focused follow-ups. + +- 2026-10-15T15:57:45Z — Recorded the explicit reply "yes confirmed" and concluded the foundational interview. The actual displayed confirmation question is now stored; earlier prepared wording was: Does the consolidated product foundation accurately capture our shared understanding, including the recorded focused follow-ups and the fact that no technical stack has been selected? diff --git a/.planning/decisions/20261015T085738Z-3/scope-review.md b/.planning/decisions/20261015T085738Z-3/scope-review.md new file mode 100644 index 0000000..120b6fd --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/scope-review.md @@ -0,0 +1,51 @@ +# Product foundation — scope review + +This product foundation is confirmed by the user. It records agreed scope and explicitly deferred work; implementation and live-use prerequisites remain in the follow-ups. The [session index](session.md) links every decision and original reply. + +## Platform and people + +Medora is a functional practice-management platform enhanced by integrated AI agents. Practices/clinics organize doctors, receptionists and optional locations. A person can have separate practice memberships; records remain practice-scoped. Owner/Admin is an explicit practice account responsibility added in Q42, alongside Doctor, Receptionist and Patient roles. Role combinations and precise permissions are still open. + +Staff have usable calendars, request queues, patient profiles and private assistant conversations. Patient booking is natural WhatsApp conversation, without requiring a separate booking UI. Staff can manage operational records directly. + +## Initial patient journey + +A practice connects a WhatsApp line and configures the doctors it represents. The line may be personally used or shared; supported onboarding modes require verification. The line holder is the communication contact and may book for another patient. Reuse verified returning contact-patient details, and verify uncertain access before disclosing existing information or changing bookings. + +The agent checks actual Medora availability, obtains minimum booking information and creates an exclusive provisional reservation. Authorized doctors/receptionists review it. Patient-facing status remains pending until approval and successful execution. A configured staffed-hours budget and pre-appointment cutoff bound the hold; expiry releases the slot and triggers notification. + +Patients can make basic rescheduling requests through WhatsApp. Replacement times require agreement; the patient can decline and cancel. Verified cancellation executes immediately and notifies staff. Keep the original appointment until the replacement is approved and accepted, unless its cancellation or unavailability is explicit. + +## Profiles and conversation + +Start with identity/contact details, appointment history, patient-reported visit reasons and short appointment-specific intake. Doctors approve questions and authorized staff may correct source-labelled information. Optional intake follows reservation; missing nonessential replies alone do not block confirmation. Full medical-record management remains outside the initial increment. + +The agent answers approved practical practice information and routes uncertain questions to staff. Reply in the speaking user's language, remember the preference until changed, and keep it distinct from the represented patient's profile. Initial staff UI locales are English, French, Arabic and Spanish; future AI-generated translations stay registered. + +## Human review and collaboration + +A configured default staff member owns handoffs; a backup and shared authorized queue provide coverage. Agent context may update silently while humans converse; replies wait for invocation/control return. A tag alone is not authority for schedule/record changes. + +Staff conversations are private. Selected read-only messages can be shared with named authorized same-practice colleagues, respecting record permissions. One-to-one human handoff is the beta baseline. Optional patient groups can be added for eligible consenting participants after eligibility, invitations and invocation have been verified. + +## Operations and rollout + +Medora is the initial authoritative schedule. External calendar synchronization is later work. Essential configuration precedes booking activation; setup can be saved/resumed and a guided test is optional. Successfully confirmed appointments remain confirmed if a notification fails; delivery state stays distinct, staff see failures and retries follow policy. + +Build incrementally while preserving the full feature register. Beta users receive early access before broader advertising. There are no current practitioner validation partners. The beta countries remain explicitly undecided. + +## Session confirmation + +All interview choices are confirmed or explicitly deferred. The user explicitly replied **"yes confirmed"**; [D040](D040-shared-understanding-confirmation.md) preserves the question, reply and interpretation. This is confirmation of the product foundation; deferred decisions remain unresolved. + +## Accepted focused follow-ups + +The user accepted these deferrals in Q47. Resolve each before its affected feature is implemented or used: + +- [Define detailed booking and rescheduling policies](../../follow-ups/20261015T155426Z-define-detailed-booking-policies/follow-up.md): Before implementing the affected scheduling policies or activating them for a practice. +- [Define identity, permissions and sharing access rules](../../follow-ups/20261015T155426Z-define-identity-permissions-and-sharing/follow-up.md): Before enabling affected record access, membership administration, sharing or booking changes. +- [Define handoff, group and notification workflows](../../follow-ups/20261015T155426Z-define-handoff-and-notification-workflows/follow-up.md): Before implementing or enabling the corresponding handoff, group or delivery-failure flows. +- [Define profile, intake and correction details](../../follow-ups/20261015T155426Z-define-profile-fields-and-intake-details/follow-up.md): Before implementing affected profile/intake behavior or collecting real patient intake. +- [Define beta validation and public-release criteria](../../follow-ups/20261015T155426Z-define-beta-validation-and-release-gates/follow-up.md): Before inviting real beta practices or claiming readiness for broader advertising. + +All existing clinical-safety, privacy, provenance and truthful-operation constraints continue to apply. No technical stack has been selected and no application is implemented. diff --git a/.planning/decisions/20261015T085738Z-3/session.md b/.planning/decisions/20261015T085738Z-3/session.md new file mode 100644 index 0000000..ee75678 --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/session.md @@ -0,0 +1,196 @@ +--- +{ + "schema_version": 1, + "id": "20261015T085738Z-3", + "title": "Medora product functionality and initial scope", + "status": "confirmed", + "created_at": "2026-10-15T08:57:38Z", + "updated_at": "2026-10-15T15:57:45Z", + "repository": "codeonym-org/medora", + "issue_number": 3, + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "participants": [ + "user", + "assistant" + ], + "facilitator": "assistant", + "origin": { + "conversation_url": null, + "message_reference": "User message invoking grill-me and requesting durable planning schemas", + "related_task": "Explore product functionality; persist planning instructions" + }, + "predecessor_sessions": [], + "supersedes": [], + "superseded_by": [], + "related_follow_ups": [ + ".planning/follow-ups/20261015T102802Z-select-internationalization-and-localization-libraries/follow-up.md", + ".planning/follow-ups/20261015T110819Z-ai-generated-additional-ui-translations/follow-up.md", + ".planning/follow-ups/20261015T121349Z-choose-beta-operating-countries/follow-up.md", + ".planning/follow-ups/20261015T142428Z-validate-whatsapp-linked-line-onboarding/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-detailed-booking-policies/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-identity-permissions-and-sharing/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-handoff-and-notification-workflows/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-profile-fields-and-intake-details/follow-up.md", + ".planning/follow-ups/20261015T155426Z-define-beta-validation-and-release-gates/follow-up.md" + ], + "confirmation_recorded_at": "2026-10-15T15:57:45Z" +} +--- + +# Purpose and context + +Sharpen Medora's first useful product experience through a recorded interview. The product vision is broad; first-user needs and initial operating assumptions remain unsettled. + +## Scope and constraints + +In scope: functionality, product ideas, target practices, patient/staff workflows, delegation boundaries, and validation. Out of scope: technical stack selection and application implementation. Existing administrative-role, clinical-safety, privacy, and truthful-confirmation constraints remain in effect. + +The user explicitly requested persistent decision and follow-up logs; see [D000](D000-planning-memory-and-scope.md). + +## Decision tree + +- First practice and daily operator → roles, receptionist collaboration, onboarding, permissions. +- Anchor problem → primary journey, minimum useful scope, observable success. +- Pilot market and languages → communication needs and local operating assumptions. +- Access to practitioners → evidence collection and pilot validation. +- Once these roots are answered: contact channels, existing schedule practices, booking/rescheduling/cancellation rules, human handoff coverage, intake and briefing boundaries, and adoption. + +These later branches are candidate questions, not assumed decisions; refine their prerequisites after round 1. + +## Decision index and rounds + +| ID / link | Round | Question | Predecessors | Status | Outcome | +| --- | --- | --- | --- | --- | --- | +| [D000](D000-planning-memory-and-scope.md) | 0 | Scope and durable records | None | confirmed | Preserve logs; no stack selection | +| [D001](D001-first-practice.md) | 1–3 | Roles and practice grouping | Root | confirmed | Practice organization; role set amended by D034 | +| [D002](D002-anchor-problem.md) | 1–2 | Initial scope | Root | confirmed | Preserve vision; basic booking and profiling first | +| [D003](D003-pilot-market.md) | 1–3 | Market and languages | Root | deferred | Four UI languages confirmed; geography deferred | +| [D004](D004-validation-access.md) | 1 | Practitioner access | Root | confirmed | No current access; advertise once working | +| [D005](D005-release-readiness.md) | 2 | Early release | D004 | confirmed | Beta early access | +| [D006](D006-booking-entry.md) | 3–4 | Patient/staff booking entry | D002 | confirmed | WhatsApp conversation is the core patient journey; private staff chat | +| [D007](D007-basic-patient-profile.md) | 3–4 | Basic profile | D002 | confirmed | Administrative profile, appointment history, visit-specific intake | +| [D008](D008-staff-chat-privacy.md) | 4 | Staff conversation visibility | D001, D006 | confirmed | Private by default; user may explicitly share | +| [D009](D009-routine-booking-authority.md) | 4 | Booking confirmation | D001, D002 | confirmed | Reserve provisionally; staff review; notify outcome | +| [D010](D010-provisional-reservation-policy.md) | 5 / Q17 | Holds and expiry | D009 | confirmed | Exclusive holds, configured expiry, notify on release | +| [D011](D011-staff-approval-permissions.md) | 5 / Q18 | Approval roles | D001, D009 | confirmed | Doctor and authorized receptionist approval | +| [D012](D012-conversation-sharing-scope.md) | 5 / Q19 | Sharing scope | D001, D008 | confirmed | Selected read-only messages to authorized same-practice colleagues | +| [D013](D013-replacement-slot-agreement.md) | 5 / Q20 | Replacement-time agreement | D009 | confirmed | Patient accepts replacement or may cancel | +| [D014](D014-review-deadline-outside-working-hours.md) | 6 / Q21 | Requests outside opening hours | D010 | confirmed | Delegated choice: staffed-hours budget capped before appointment | +| [D015](D015-practice-and-doctor-routing.md) | 6 / Q22 | Which practice are they messaging? | D001, D006 | confirmed | Practice-linked WhatsApp line, personal/shared number | +| [D016](D016-booking-for-someone-else.md) | 6 / Q23 | Booking for someone else | D006, D007 | confirmed | Communication contact can book for another patient | +| [D017](D017-optional-conversational-intake.md) | 6 / Q24 | Intake without blocking booking | D007, D009 | confirmed | Reserve with minimum data; optional intake afterwards | +| [D018](D018-linked-line-doctor-routing.md) | 7 / Q25 | Routing a linked line | D001, D015 | confirmed | Doctor/group routing, preserve patient preference | +| [D019](D019-contact-with-multiple-patient-profiles.md) | 7 / Q26 | Returning patients | D007, D016 | confirmed | Reuse verified returning-patient details | +| [D020](D020-patient-conversation-languages.md) | 7 / Q27 | Patient conversation languages | D006, D003 | confirmed | Reply in user language; remember until changed | +| [D021](D021-staff-takeover-of-patient-chat.md) | 7 / Q28 | Human takeover | D006, D011, D015 | confirmed | Human takeover confirmed; group mechanism proposed | +| [D022](D022-optional-patient-group-handoff.md) | 8 / Q29 | Optional groups | D021 | confirmed | Optional eligible/consensual groups; one-to-one fallback | +| [D023](D023-handoff-staff-assignment.md) | 8 / Q30 | Which staff joins? | D001, D011, D021 | confirmed | Default staff member configured in Medora | +| [D024](D024-agent-context-during-human-handoff.md) | 8 / Q31 | Agent awareness during handoff | D007, D021 | confirmed | Silent authorized context; invoked/returned replies only | +| [D025](D025-remembered-language-preference-owner.md) | 8 / Q32 | Whose language preference? | D016, D020 | confirmed | Preference belongs to speaking user/contact | +| [D026](D026-initial-availability-source.md) | 9 / Q33 | Where does availability come from? | D002, D009, D018 | confirmed | Medora schedule initially; external sync later | +| [D027](D027-approved-practice-information.md) | 9 / Q34 | Questions beyond appointments | D006, D023 | confirmed | Approved practical answers; reduce patient embarrassment | +| [D028](D028-notification-failure-after-confirmation.md) | 9 / Q35 | A confirmation message fails | D009, D013, D015 | confirmed | Keep booking confirmed; delivery failures visible/retried | +| [D029](D029-first-contact-existing-record-access.md) | 9 / Q36 | Access to existing patient information | D016, D019 | confirmed | Staff verifies uncertain access to existing records | +| [D030](D030-staff-daily-workspace.md) | 10 / Q37 | The staff workspace | D007, D009, D026 | confirmed | Functional management platform enhanced with AI agents | +| [D031](D031-practice-setup-before-activation.md) | 10 / Q38 | Practice setup | D015, D023, D026 | confirmed | Essential setup; optional test; save/resume | +| [D032](D032-first-increment-appointment-lifecycle.md) | 10 / Q39 | Changes and cancellations in beta | D002, D006, D013, D029 | confirmed | Basic cancellations/rescheduling in initial beta | +| [D033](D033-intake-template-and-profile-review.md) | 10 / Q40 | Who controls intake? | D007, D017, D027 | confirmed | Doctor-approved intake, source labels and corrections | +| [D034](D034-practice-configuration-ownership.md) | 11 / Q42 | Who manages the practice? | D001, D011, D023, D030 | confirmed | Practice Owner/Admin account; operational roles retained | +| [D035](D035-verified-patient-cancellation.md) | 11 / Q43 | Patient cancellation | D013, D029, D032 | confirmed | Verified patient cancels immediately; staff notified | +| [D036](D036-default-staff-unavailable.md) | 11 / Q44 | Default staff unavailable | D011, D014, D023, D030 | confirmed | Configured backup and shared authorized handoff queue | +| [D037](D037-keep-original-during-rescheduling.md) | 12 / Q45 | While rescheduling is pending | D009, D013, D032 | confirmed | Keep original until accepted/approved replacement | +| [D038](D038-optional-group-release-timing.md) | 12 / Q46 | Groups in the first beta | D002, D005, D021, D022 | confirmed | One-to-one beta baseline; verified optional groups later | +| [D039](D039-focused-design-followups.md) | 12 / Q47 | Detailed design follow-ups | D000, D002, D030 | confirmed | Focused details explicitly deferred with implementation/use gates | +| [D040](D040-shared-understanding-confirmation.md) | 13 / final review | Shared understanding confirmation | D037–D039 and scope review | confirmed | User: yes confirmed | + +## Current frontier + +Empty for this foundational product interview. The user explicitly confirmed the consolidated understanding. Detailed branches are accepted deferrals linked below; their own sessions will establish future frontiers. + +## Unresolved or deferred branches + +The accepted focused follow-ups remain open: booking rules; identity/permissions/sharing; handoff/groups/delivery; profile/intake details; beta acceptance. Resolve each before affected implementation or use. Existing geography, translation/library and WhatsApp onboarding follow-ups also remain open. No unresolved detail is treated as completed by this session confirmation. + +## Shared understanding + +The core patient journey is natural WhatsApp conversation: the agent handles appointment requests and appointment questions directly. A separate patient booking UI is not required. The agent reserves a slot provisionally; staff confirmation/rejection/changes determine the outcome, which the agent communicates. Staff have private management conversations and may explicitly share material; details remain open. Basic profiling includes identity/contact details, appointment history, patient-reported visit reasons, and short appointment-specific intake; full clinical-record features are outside the first increment. The accepted practice model, operational roles plus the explicit Owner/Admin account (D034), English code, EN/FR/AR/ES UI, and beta early access remain. Geography is explicitly deferred. + +Round 5 confirms exclusive pending holds with practice-configured expiry and patient notification on release; doctors and authorized receptionists handle routine review. Sharing initially means selected read-only messages to named authorized colleagues in the same practice. A patient must agree to a replacement time and may cancel if it does not fit their schedule. No monetary cancellation policy is inferred. + +Round 6: Medora attaches to a practice-linked external communication line, with WhatsApp the only initial app. A number may be personal or shared; account/API compatibility is not assumed. The line holder is the communication contact and may book for someone else. Minimum booking information permits a provisional hold; optional conversational intake follows without blocking staff confirmation. The user delegated Q21: use a staffed-hours review budget capped by a pre-appointment cutoff, releasing/notifying at the earlier limit. Numerical settings remain open. + +Round 7 confirms line-to-doctor/group routing and reuse of verified returning-patient details. The agent replies in the user's own language, remembers it until changed, and is not limited to the four UI locales by that instruction. Human takeover is confirmed. A per-patient group with staff and tag-driven awareness is a proposal, not an accepted universal mechanism; account eligibility, invitation limits and unverified native tagging need to be reflected in the design. + +Round 8 confirms optional patient groups for eligible consenting participants, with a one-to-one human handoff fallback. Handoffs target a default staff member configured on Medora, not all staff or necessarily a receptionist. Medora retains authorized context silently during human ownership and replies on invocation/control return; that does not authorize state changes. Remembered language belongs to the speaking account/contact, separately from the represented patient. + +Round 9: Medora holds the initial authoritative schedule; external calendar sync can come later. The agent answers approved practical practice questions, with the user identifying reduced embarrassment as a benefit. Confirmed appointment status survives a notification failure; staff see the failure and retries follow policy. Staff verify uncertain/new contact-patient relationships before existing-record access or booking changes; new requests can enter review without disclosure. + +Round 10: Medora is a functional practice-management platform enhanced by integrated AI agents. Staff have direct calendars, request queues and profile views alongside assistant chat; this does not change the conversational WhatsApp patient journey or authorize all roadmap features at once. Basic cancellation/rescheduling requests are included in initial beta. Doctors approve intake questions and authorized staff can correct source-labelled information. Practice setup was accepted tentatively; a mandatory test-booking activation gate remains unconfirmed. + +Round 11 resolves setup: required essentials, optional test and save/resume. A practice Owner/Admin account is explicit, partially amending the initial three-role framing without implying global platform authority or automatic clinical access. Verified patient cancellations execute immediately with staff notification. Backup staff and a shared authorized handoff queue are accepted. See [the consolidated scope review](scope-review.md) for current rather than historical summaries. + +Round 12 confirms preservation of the original appointment while a replacement is pending, baseline one-to-one beta handoff before optional verified groups, and explicit durable deferrals for detailed design. The [scope review](scope-review.md) is updated with those choices and the five created follow-ups. Final session confirmation remains pending. + +Final confirmation: the user replied "yes confirmed" to the consolidated summary. The [scope review](scope-review.md) is the agreed product foundation; the no-stack scope and detailed follow-up prerequisites remain in force. + +## Final user confirmation + +Confirmed, recorded 2026-10-15T15:57:45Z. Source: current conversation, final reply to the consolidated summary and scope review. + +> yes confirmed + +[D040](D040-shared-understanding-confirmation.md) contains the displayed question, reply and interpretation. The recording timestamp is not an inferred original message-send timestamp. This confirms product understanding; it does not resolve follow-ups or authorize unrelated actions. + +## Related follow-ups and work + +Issue: https://github.com/codeonym-org/medora/issues/3. Draft PR: https://github.com/codeonym-org/medora/pull/4. + +[Select internationalization/localization libraries later](../../follow-ups/20261015T102802Z-select-internationalization-and-localization-libraries/follow-up.md). + +[Feature register](../../feature-register.md). [Additional AI translations](../../follow-ups/20261015T110819Z-ai-generated-additional-ui-translations/follow-up.md). + +[Beta operating countries](../../follow-ups/20261015T121349Z-choose-beta-operating-countries/follow-up.md). + +[WhatsApp linked-line onboarding research](../../follow-ups/20261015T142428Z-validate-whatsapp-linked-line-onboarding/follow-up.md). + +[Official-source WhatsApp group feasibility](whatsapp-group-feasibility.md). + +[Consolidated scope review](scope-review.md). + +Focused detail records: + +- [Define detailed booking and rescheduling policies](../../follow-ups/20261015T155426Z-define-detailed-booking-policies/follow-up.md) +- [Define identity, permissions and sharing access rules](../../follow-ups/20261015T155426Z-define-identity-permissions-and-sharing/follow-up.md) +- [Define handoff, group and notification workflows](../../follow-ups/20261015T155426Z-define-handoff-and-notification-workflows/follow-up.md) +- [Define profile, intake and correction details](../../follow-ups/20261015T155426Z-define-profile-fields-and-intake-details/follow-up.md) +- [Define beta validation and public-release criteria](../../follow-ups/20261015T155426Z-define-beta-validation-and-release-gates/follow-up.md) + +## History + +- 2026-10-15T08:57:38Z — Assistant created session, recorded the supplied scope, and prepared round 1. + +- 2026-10-15T10:28:02Z — Assistant saved all first-round answers, preserved both Q4 messages, recorded partial decisions, captured the library follow-up, and prepared round 2. + +- 2026-10-15T11:08:19Z — Round 2 replies saved verbatim. Initial scope/languages/beta access recorded; organization recommendation and round 3 questions prepared. Full feature register and translation-extension follow-up added. + +- 2026-10-15T12:13:49Z — Saved round 3 replies verbatim, confirmed the practice model, clarified accepted channel direction, kept profile scope open, captured geography deferral, and prepared round 4. + +- 2026-10-15T13:46:49Z — Recorded round 4 replies, corrected the mistaken patient-UI framing, confirmed profile scope/private staff conversations/staff-reviewed reservations, and prepared round 5. + +- 2026-10-15T13:52:30Z — Saved round 5 replies; confirmed expiry, approval, sharing and patient replacement/cancellation choices; prepared round 6. + +- 2026-10-15T14:24:28Z — Saved round 6 replies, selected the delegated review-clock policy, clarified linked-line/contact concepts, and prepared round 7; integration feasibility is deferred. + +- 2026-10-15T14:38:24Z — Saved round 7 replies, researched the proposed group flow against official documentation, and prepared round 8 without treating tentative group behavior as confirmed. + +- 2026-10-15T14:45:47Z — Saved round 8 choices, including user-configured default staff, and prepared round 9 core workflow questions. + +- 2026-10-15T14:52:33Z — Saved round 9 choices and the product owner's embarrassment rationale; prepared round 10 for initial staff/practice workflows. + +- 2026-10-15T15:38:29Z — Saved round 10, clarified the full-platform direction, kept tentative onboarding open, and prepared round 11 operational decisions. + +- 2026-10-15T15:44:38Z — Saved round 11; linked Owner/Admin role-set amendment, resolved setup/cancellation/backup choices, and prepared a scope review with three remaining scope decisions. + +- 2026-10-15T15:54:26Z — Saved Q45–Q47; created five user-approved focused follow-ups; updated scope review; set awaiting-confirmation and prepared D040. + +- 2026-10-15T15:57:45Z — Explicit final confirmation saved. Session status changed from awaiting-confirmation to confirmed; detailed follow-ups remain open. diff --git a/.planning/decisions/20261015T085738Z-3/whatsapp-group-feasibility.md b/.planning/decisions/20261015T085738Z-3/whatsapp-group-feasibility.md new file mode 100644 index 0000000..21c48ec --- /dev/null +++ b/.planning/decisions/20261015T085738Z-3/whatsapp-group-feasibility.md @@ -0,0 +1,21 @@ +# WhatsApp group feasibility — product evidence + +Checked 2026-10-15T14:38:24Z. This is a product-feasibility check, not a stack decision or a working integration. Findings were read from official Meta documentation; direct `.md` representations were used when browser requests failed. + +## Verified facts + +- Meta restricts automated groups to Official Business Accounts. Its overview lists eight participants, 10,000 groups per business number, and one Cloud API business per group. Business app numbers and Multi-solution Conversations numbers are excluded. The participant list cannot be hidden. [Official overview](https://developers.facebook.com/documentation/business-messaging/whatsapp/groups) +- Participants choose to join using an invitation; the API cannot add them directly. [Group management](https://developers.facebook.com/documentation/business-messaging/whatsapp/groups/reference) +- Incoming group messages identify the group and sender. [Group messaging](https://developers.facebook.com/documentation/business-messaging/whatsapp/groups/groups-messaging) + +## Implications and uncertainties + +The assistant infers that an eligible integration could retain conversation context while suppressing automatic replies. That is application behavior, not a verified built-in agent feature. Native tag/mention detection has not been verified in the reviewed references; the absence of an example does not prove impossibility. + +Ordinary staff joining as invited WhatsApp users appears consistent with the invitation model, but staff-specific behavior was not separately verified. No interpretation of whether the business counts within the eight-participant cap is asserted. + +An automatic group cannot be assumed for every personally used/shared linked number. The assistant recommends an optional group flow for eligible practices with opt-in participants and a one-to-one handoff fallback. These recommendations await the user decision in D022. Group membership, disclosure, lifecycle, tags, and authorized updates need explicit product rules. + +## Sources + +Each fact above links to its source. Recheck current official requirements during integration planning; no credentials, messages, groups, or external account state were changed. diff --git a/.planning/feature-register.md b/.planning/feature-register.md new file mode 100644 index 0000000..e5cf95c --- /dev/null +++ b/.planning/feature-register.md @@ -0,0 +1,38 @@ +# Product feature register + +Keep the full vision discoverable while delivering incrementally. This register summarizes [the product vision](../docs/product-vision.md) and [the current scope decision](decisions/20261015T085738Z-3/D002-anchor-problem.md); it is not an implementation checklist or a promise of delivery dates. + +| Capability | Current commitment | Details still to decide | +| --- | --- | --- | +| Basic appointment booking | First increment, confirmed by user | Linked-line WhatsApp booking, exclusive expiring holds, staff review confirmed | +| Basic patient profiling | First increment, confirmed by user | Administrative profile and per-appointment intake confirmed; exact fields/identity open | +| Owner/Admin, Doctor, Receptionist, Patient | Owner/Admin added by Q42; operational roles retained | Role-specific permissions, memberships and journeys | +| English, French, Arabic, Spanish UI | Initial language list confirmed | Locale variants, language switching, translation review | +| Beta-user early access | Confirmed rollout stage | Recruitment, beta scope, success measures, exit criteria | +| Availability and calendar management | Medora is initial scheduling source, confirmed | Minimum setup, controls and calendar views | +| Rescheduling and cancellation | Basic cancellation/rescheduling requests in initial beta, confirmed | Immediate verified cancellation and staff notice; keep original while replacement is pending | +| Booking confirmations | Staff approval required after provisional reservation | Authorized staff review and staffed-hours/cutoff policy chosen; numerical settings open; confirmed booking survives visible/retried delivery failure | +| Reminders and notification preferences | Preserved planned capability; sequencing open | Timing, channels, opt-in behavior | +| Short patient intake and structured summaries | Doctor-approved intake, source-labelled profiles and staff corrections confirmed | Exact templates, correction rights, summary depth | +| Pre-consultation briefing and daily overview | Preserved planned capability; sequencing open | First-release breadth, presentation, update timing | +| Functional staff platform | Direct calendar, review-queue and patient-profile views confirmed; AI enhances platform | Detailed navigation and interaction design | +| Doctor/staff conversational assistant | Private staff conversations and optional sharing confirmed | Selected read-only messages to authorized same-practice colleagues confirmed; revocation/details open | +| Patient conversational appointment requests | WhatsApp agent handles booking and appointment inquiries in chat | Additional channels, conversation languages, human handoff | +| Request priority and human review queues | Preserved planned capability; sequencing open | Configured protocols, reviewer availability, escalation | +| Waiting lists and cancellation slot offers | Preserved planned capability; sequencing open | Eligibility and offer/acceptance behavior | +| Practice policies, templates, automation settings | Essential configuration before activation confirmed; optional guided test | Exact settings, ownership delegation and validation details | +| Multiple doctors/clinics and locations | Practice/clinic organization model confirmed; staged delivery | Practice membership, location scheduling, access boundaries | +| Calendar and authorized health-record integrations | Preserved planned capability; sequencing open | Integration scope, operational boundaries | +| Analytics and workload insights | Preserved planned capability; sequencing open | Measures and validated baselines | +| Advanced automation and clinically governed triage | Preserved later vision; no current implementation commitment | Governance, scope and human review requirements | +| Practice-linked communication line | WhatsApp only initially; personal/shared number requirement confirmed | Doctor/group routing confirmed; supported onboarding paths and handoff mechanism open | +| Booking for someone else | Communication contact may differ from patient, confirmed | Multiple-profile handling and authorization details | +| Optional conversational intake | After minimum-data reservation; nonessential answers may be skipped | Exact fields and practice templates | +| Returning-patient convenience | Reuse verified contact-patient details, confirmed | Staff verifies uncertain relationships before existing-record access/changes; exact evidence/corrections open | +| Agent language preference | Reply in user language and remember until changed, confirmed | Speaking-account/contact owner confirmed; uncertain/unsupported language handling open | +| Human takeover | Confirmed capability | Configured default/backup staff, authorized queue and silent context confirmed; transfer/failure details open | +| Per-patient WhatsApp groups | Optional verified extension after baseline one-to-one beta handoff | Configured default staff; invitations, tags and lifecycle details open | +| Practical practice questions | Approved hours/address/fees/preparation answers confirmed | Information maintenance, review and uncertainty handling | +| AI-generated additional translations | User-requested extension capability | Generation, review, publication, fallback behavior | + +Safety, privacy, provenance, authorization, and truthful operation reporting remain cross-cutting requirements, as documented in AGENTS.md. No feature is implemented by virtue of appearing here. Update this register as decisions become explicit; preserve the record of changed or rejected scope. diff --git a/.planning/follow-ups/20261015T102802Z-select-internationalization-and-localization-libraries/follow-up.md b/.planning/follow-ups/20261015T102802Z-select-internationalization-and-localization-libraries/follow-up.md new file mode 100644 index 0000000..a029f8f --- /dev/null +++ b/.planning/follow-ups/20261015T102802Z-select-internationalization-and-localization-libraries/follow-up.md @@ -0,0 +1,99 @@ +--- +{ + "schema_version": 1, + "id": "FU-20261015T102802Z-select-internationalization-and-localization-libraries", + "title": "Select internationalization and localization libraries when choosing the stack", + "kind": "build", + "status": "captured", + "created_at": "2026-10-15T10:28:02Z", + "updated_at": "2026-10-15T11:08:19Z", + "observed_at": null, + "reported_by": "user", + "owner": null, + "priority": null, + "severity": null, + "origin": { + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "decision": ".planning/decisions/20261015T085738Z-3/D003-pilot-market.md", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "pr_url": "https://github.com/codeonym-org/medora/pull/4", + "conversation_reference": "First-round Q3 reply in the current product-grilling conversation", + "file_or_component": "User interface localization", + "revision": null + }, + "affected_components": [ + "UI text", + "Locale-aware formatting", + "Language preferences" + ], + "related_decisions": [ + ".planning/decisions/20261015T085738Z-3/D003-pilot-market.md" + ], + "dependencies": [ + "Application stack decision (not yet made)", + "Locale variants and formatting requirements (not yet settled)" + ], + "related_follow_ups": [], + "duplicate_of": null, + "tracking_issue": null, + "revisit": { + "trigger": "When technical stack selection begins and initial language/locale requirements are known", + "due_at": null + }, + "resolution": { + "resolved_at": null, + "outcome": null, + "evidence": [] + } +} +--- + +# Summary + +Select appropriate internationalization and localization libraries later, preserving the user's requirement for English code and a translated/localized UI. + +## Why — motivation and impact + +The user explicitly asked for library-supported UI translation/localization. Preserve this requirement so it is not lost when technical choices are made after the product interview. Delivery priority and impact severity have not been assessed. + +## When and where — discovery context + +Captured 2026-10-15T10:28:02Z during the first product-grilling round in [D003](../../decisions/20261015T085738Z-3/D003-pilot-market.md). The original message time is unknown. Library selection belongs to technical planning, explicitly outside the active session. + +## Original observation or request + +> Q3: CODE is ENG, UI is translated using i18n libraries and localisation libraries .. + +## Analysis + +Confirmed: English code; translated/localized UI initially in English, French, Arabic, and Spanish. The library evaluation needs right-to-left UI support for Arabic. Unknown: application stack, regional locale variants, and formatting policies. No library is selected. UI translation and AI conversation language coverage remain separate requirements. + +## Affected components and boundaries + +UI text, language preferences, and locale-aware formatting are potential affected areas. Exact code components do not exist yet. Backend or conversational language handling is not specified by this request alone. + +## Reproduction or motivating example + +Motivating example: a user views interface labels and dates in their selected supported locale while source identifiers remain English. This is illustrative, not an approved detailed UX requirement. Bug reproduction is not applicable. + +## Options and proposed next action + +After product language requirements and the application stack are known, compare compatible libraries and translation workflows against those requirements. Capture a justified selection and configuration plan. Do not select or install libraries during this product interview. + +## Dependencies and revisit trigger + +Revisit during stack selection. D003 now identifies four initial languages; regional locale/formatting details remain unresolved. No due date or owner is assigned. + +## Acceptance and verification + +A later technical decision documents library choices, their rationale, supported translation/formatting needs, and a verification plan appropriate to the chosen stack. Link that decision here before closing the follow-up. + +## Resolution + +Pending. Capturing this item does not authorize implementation or change the session scope. + +## Extra notes and history + +- 2026-10-15T10:28:02Z — Assistant captured the user's requirement as deferred technical work; no dependency was selected or installed. + +- 2026-10-15T11:08:19Z — Initial languages updated from the round 2 reply; library selection remains deferred. diff --git a/.planning/follow-ups/20261015T110819Z-ai-generated-additional-ui-translations/follow-up.md b/.planning/follow-ups/20261015T110819Z-ai-generated-additional-ui-translations/follow-up.md new file mode 100644 index 0000000..777e403 --- /dev/null +++ b/.planning/follow-ups/20261015T110819Z-ai-generated-additional-ui-translations/follow-up.md @@ -0,0 +1,99 @@ +--- +{ + "schema_version": 1, + "id": "FU-20261015T110819Z-ai-generated-additional-ui-translations", + "title": "Define AI-generated additional UI translations", + "kind": "feat", + "status": "captured", + "created_at": "2026-10-15T11:08:19Z", + "updated_at": "2026-10-15T11:08:19Z", + "observed_at": null, + "reported_by": "user", + "owner": null, + "priority": null, + "severity": null, + "origin": { + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "decision": ".planning/decisions/20261015T085738Z-3/D003-pilot-market.md", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "pr_url": "https://github.com/codeonym-org/medora/pull/4", + "conversation_reference": "Round 2 Q7 reply", + "file_or_component": "UI translations", + "revision": null + }, + "affected_components": [ + "UI translations", + "Language availability", + "Translation review" + ], + "related_decisions": [ + ".planning/decisions/20261015T085738Z-3/D003-pilot-market.md" + ], + "dependencies": [ + "Definition of supported UI text and templates", + "Translation review and publication policy" + ], + "related_follow_ups": [ + ".planning/follow-ups/20261015T102802Z-select-internationalization-and-localization-libraries/follow-up.md" + ], + "duplicate_of": null, + "tracking_issue": null, + "revisit": { + "trigger": "When planning languages beyond the initial English, French, Arabic, and Spanish release", + "due_at": null + }, + "resolution": { + "resolved_at": null, + "outcome": null, + "evidence": [] + } +} +--- + +# Summary + +Preserve the user-requested ability to generate additional UI translations with AI beyond the initial four languages. + +## Why — motivation and impact + +The user wants language expansion without manually drafting every translation. This capability must remain recorded while the first increment focuses on booking and profiling. No priority or delivery date is assigned. + +## When and where — discovery context + +Recorded 2026-10-15T11:08:19Z during round 2 Q7. Original message timestamp is unavailable. The extension belongs to later language planning; no AI provider or implementation is being selected during this product session. + +## Original observation or request + +> Q7: we will start with ENGLISH, FRENCH, ARABIC, SPANISH (other languages can be auto generated using AI models) + +## Analysis + +The initial language list and AI-generation idea are explicit. Generation timing, supported content, approval, publication, quality expectations, fallback behavior, and accountability are unspecified. The assistant recommends defining review before publishing generated translations; the user has not accepted that policy yet. Generation does not establish that every language is fully supported. + +## Affected components and boundaries + +UI translations, available-language lists, fallback content, and review workflows. Clinical templates and AI conversation languages are not automatically included. Library selection is separately tracked. + +## Reproduction or motivating example + +A later language is requested, AI drafts translated interface strings, and the eventual approved workflow determines when that language becomes available. This scenario illustrates the capability; approval details remain open. Not a bug report. + +## Options and proposed next action + +Clarify whether generation occurs during development, through a staff-requested workflow, or dynamically for users. Decide review, publication, fallback, and supported-content boundaries before implementation. + +## Dependencies and revisit trigger + +Revisit when expanding beyond the initial four languages. Use the UI translation structure and agreed review/publication requirements. No deadline or owner is assigned. + +## Acceptance and verification + +A future decision defines supported content, generation trigger, review/publication policy, and fallback behavior. A resulting implementation must demonstrate those behaviors before this item is resolved. + +## Resolution + +Pending; capturing the capability is not authorization to publish generated content or invoke an AI service. + +## Extra notes and history + +- 2026-10-15T11:08:19Z — Assistant captured the request as a distinct language-expansion follow-up. diff --git a/.planning/follow-ups/20261015T121349Z-choose-beta-operating-countries/follow-up.md b/.planning/follow-ups/20261015T121349Z-choose-beta-operating-countries/follow-up.md new file mode 100644 index 0000000..22ac3ae --- /dev/null +++ b/.planning/follow-ups/20261015T121349Z-choose-beta-operating-countries/follow-up.md @@ -0,0 +1,94 @@ +--- +{ + "schema_version": 1, + "id": "FU-20261015T121349Z-choose-beta-operating-countries", + "title": "Choose beta operating countries before recruitment and local policy decisions", + "kind": "question", + "status": "captured", + "created_at": "2026-10-15T12:13:49Z", + "updated_at": "2026-10-15T12:13:49Z", + "observed_at": null, + "reported_by": "user", + "owner": null, + "priority": null, + "severity": null, + "origin": { + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "decision": ".planning/decisions/20261015T085738Z-3/D003-pilot-market.md", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "pr_url": "https://github.com/codeonym-org/medora/pull/4", + "conversation_reference": "Round 3 Q12 reply", + "file_or_component": "Beta scope", + "revision": null + }, + "affected_components": [ + "Beta recruitment", + "Practice onboarding", + "Country-specific operating rules" + ], + "related_decisions": [ + ".planning/decisions/20261015T085738Z-3/D003-pilot-market.md" + ], + "dependencies": [], + "related_follow_ups": [], + "duplicate_of": null, + "tracking_issue": null, + "revisit": { + "trigger": "Before setting beta recruitment eligibility or country-specific operating rules", + "due_at": null + }, + "resolution": { + "resolved_at": null, + "outcome": null, + "evidence": [] + } +} +--- + +# Summary + +Choose the countries in which beta practices will operate. The user explicitly left this undecided during product discovery. + +## Why — motivation and impact + +A language list does not identify the operating market. Beta eligibility and country-specific operational requirements cannot be finalized from the four UI languages alone. No priority or severity is assigned. + +## When and where — discovery context + +Recorded 2026-10-15T12:13:49Z from round 3 Q12 in [D003](../../decisions/20261015T085738Z-3/D003-pilot-market.md). The original message timestamp is unknown. The user chose not to settle geography now, so preserve the question for beta planning without blocking general product exploration. + +## Original observation or request + +> q12: undecided + +## Analysis + +Confirmed UI languages: English, French, Arabic, Spanish. Country selection remains open; no country is inferred from those languages or the development timezone. No jurisdiction-specific legal or clinical conclusions have been researched or made. + +## Affected components and boundaries + +Beta eligibility, practice onboarding, and country-specific operating policies. General booking and profile design can continue with uncertainty explicitly recorded. + +## Reproduction or motivating example + +When deciding which practices may join beta, identify supported operating countries before applying market-specific rules. This is a planning question, not a bug. + +## Options and proposed next action + +Ask the user to select one or more beta markets when recruitment scope is defined. Then identify requirements needing evidence or qualified review. No recruitment or external outreach is authorized by this record. + +## Dependencies and revisit trigger + +Revisit before setting beta recruitment eligibility or country-specific operating rules. No date or assigned owner is known. + +## Acceptance and verification + +Record an explicit user decision on beta operating countries, link it from D003, and identify any newly unblocked product-policy questions. Do not close based solely on selecting interface languages. + +## Resolution + +Pending. + +## Extra notes and history + +- 2026-10-15T12:13:49Z — Assistant captured the explicitly undecided geography choice as a follow-up. diff --git a/.planning/follow-ups/20261015T142428Z-validate-whatsapp-linked-line-onboarding/follow-up.md b/.planning/follow-ups/20261015T142428Z-validate-whatsapp-linked-line-onboarding/follow-up.md new file mode 100644 index 0000000..3523a39 --- /dev/null +++ b/.planning/follow-ups/20261015T142428Z-validate-whatsapp-linked-line-onboarding/follow-up.md @@ -0,0 +1,107 @@ +--- +{ + "schema_version": 1, + "id": "FU-20261015T142428Z-validate-whatsapp-linked-line-onboarding", + "title": "Validate WhatsApp linked-line onboarding for personal/shared numbers", + "kind": "research", + "status": "captured", + "created_at": "2026-10-15T14:24:28Z", + "updated_at": "2026-10-15T14:38:24Z", + "observed_at": null, + "reported_by": "user", + "owner": null, + "priority": null, + "severity": null, + "origin": { + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "decision": ".planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "pr_url": "https://github.com/codeonym-org/medora/pull/4", + "conversation_reference": "Round 6 Q22 linked-line requirement", + "file_or_component": "Practice WhatsApp connection", + "revision": null + }, + "affected_components": [ + "Practice onboarding", + "Linked WhatsApp lines", + "Agent/human communication" + ], + "related_decisions": [ + ".planning/decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md", + ".planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md" + ], + "dependencies": [ + "Product linked-line scope", + "Later integration planning" + ], + "related_follow_ups": [], + "duplicate_of": null, + "tracking_issue": null, + "revisit": { + "trigger": "When WhatsApp integration and onboarding are technically evaluated, before promising supported connection modes", + "due_at": null + }, + "resolution": { + "resolved_at": null, + "outcome": null, + "evidence": [] + }, + "sources": [ + "https://developers.facebook.com/documentation/business-messaging/whatsapp/groups", + "https://developers.facebook.com/documentation/business-messaging/whatsapp/groups/reference", + "https://developers.facebook.com/documentation/business-messaging/whatsapp/groups/groups-messaging" + ] +} +--- + +# Summary + +Research the supported onboarding paths for a practice connecting a personally used or shared WhatsApp number to Medora. The product requirement is recorded; integration compatibility is not yet verified. + +## Why — motivation and impact + +The user defines Medora as a platform attached to external communication lines. The later connection flow must make this possible through supported WhatsApp capabilities without promising unverified personal-account or existing-number behavior. + +## When and where — discovery context + +Recorded 2026-10-15T14:24:28Z during product discovery, Q22 in [D015](../../decisions/20261015T085738Z-3/D015-practice-and-doctor-routing.md). Original message timestamp unknown. Integration research is outside the current no-stack product session. + +## Original observation or request + +> q22: medora is a platform, it requires its users (practice) to link a client facing communication app (currently only whatsapp will be used) so, the whatsapp app will need a linked line (like whatsapp busniess etc ...) so it can be either one of their personal phone numbers, or a shared one, the idea is that modera attaches to a line for edge communication + +## Analysis + +A personal/shared phone number is a product ownership/use category, not a confirmed WhatsApp account/API compatibility mode. No provider, account migration path, manual-coexistence behavior, credentials, or implementation has been selected or verified. Consult current official WhatsApp documentation when this work begins. + +Current official group eligibility/invitation findings are recorded in [the product feasibility note](../../decisions/20261015T085738Z-3/whatsapp-group-feasibility.md). Remaining integration work includes checking connected-number eligibility, invitation/join behavior, tag/mention delivery, ownership during takeover, and supported return-to-agent behavior. Group support is not assumed for every linked number. + +## Affected components and boundaries + +Practice line connection, account/number eligibility, disconnect/reconnect, onboarding instructions and human/agent ownership. Doctor routing is a separate product question. + +## Reproduction or motivating example + +A practice wants to connect an existing doctor-used number or shared reception number. Determine which supported onboarding path applies. This is a research scenario, not evidence of a working integration. + +## Options and proposed next action + +Research official capabilities against the accepted requirements; document supported/unsupported modes, any user-visible setup steps, coexistence constraints and failure states. Present any product tradeoff instead of silently replacing the conversational journey. + +## Dependencies and revisit trigger + +Revisit during technical WhatsApp integration planning and before claiming compatibility to practices. No deadline or owner assigned. + +## Acceptance and verification + +Cited official findings identify supported account/number connection modes and operational limitations. A testable onboarding plan and documented product tradeoffs link back here before resolution. Verify or explicitly reject native mention/tag triggers and group compatibility for each supported onboarding mode before promising the proposed group handoff. Distinguish message ingestion from replies and authorized state changes. + +## Resolution + +Pending. No external app/account connection or patient-data transfer is authorized by this record. + +## Extra notes and history + +- 2026-10-15T14:24:28Z — Captured future integration research without selecting a stack or asserting compatibility. + +- 2026-10-15T14:38:24Z — Added per-patient group/tag proposal and official eligibility evidence; integration verification remains open. diff --git a/.planning/follow-ups/20261015T155426Z-define-beta-validation-and-release-gates/follow-up.md b/.planning/follow-ups/20261015T155426Z-define-beta-validation-and-release-gates/follow-up.md new file mode 100644 index 0000000..23a229a --- /dev/null +++ b/.planning/follow-ups/20261015T155426Z-define-beta-validation-and-release-gates/follow-up.md @@ -0,0 +1,108 @@ +--- +{ + "schema_version": 1, + "id": "FU-20261015T155426Z-define-beta-validation-and-release-gates", + "title": "Define beta validation and public-release criteria", + "kind": "question", + "status": "captured", + "created_at": "2026-10-15T15:54:26Z", + "updated_at": "2026-10-15T15:54:26Z", + "observed_at": null, + "reported_by": "assistant; deferral explicitly accepted by user in Q47", + "owner": null, + "priority": null, + "severity": null, + "origin": { + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "decision": ".planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "pr_url": "https://github.com/codeonym-org/medora/pull/4", + "conversation_reference": "Round 12: q47: ok; preceding Q47 proposed focused details", + "file_or_component": "Beta acceptance", + "revision": null + }, + "affected_components": [ + "Beta scope", + "Workflow validation", + "Feedback", + "Release readiness" + ], + "related_decisions": [ + ".planning/decisions/20261015T085738Z-3/D002-anchor-problem.md", + ".planning/decisions/20261015T085738Z-3/D005-release-readiness.md", + ".planning/decisions/20261015T085738Z-3/D030-staff-daily-workspace.md", + ".planning/decisions/20261015T085738Z-3/D031-practice-setup-before-activation.md", + ".planning/decisions/20261015T085738Z-3/D038-optional-group-release-timing.md", + ".planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md" + ], + "dependencies": [ + ".planning/decisions/20261015T085738Z-3/scope-review.md" + ], + "related_follow_ups": [ + ".planning/follow-ups/20261015T121349Z-choose-beta-operating-countries/follow-up.md" + ], + "duplicate_of": null, + "tracking_issue": null, + "revisit": { + "trigger": "Before inviting real beta practices or claiming readiness for broader advertising", + "due_at": null + }, + "resolution": { + "resolved_at": null, + "outcome": null, + "evidence": [] + } +} +--- + +# Summary + +Define beta validation and public-release criteria. Preserve the accepted high-level behavior while resolving the remaining detailed choices in a focused session. + +## Why — motivation and impact + +The broad product interview settled the capability and workflow direction, but the details below are not yet decided. The user explicitly accepted Q47 deferral so these choices remain discoverable and block affected implementation/use rather than becoming silent assumptions. + +## When and where — discovery context + +Captured 2026-10-15T15:54:26Z from the product discovery session linked above. The original user-message timestamp is unavailable. The active task was consolidating the product foundation; the detailed branch is deferred with user agreement. + +## Original observation or request + +Q47 asked to capture focused policy/access/communication/profile/beta details before affected implementation/use. The actual user reply was: + +> q47: ok + +The analysis and suggested next steps below are assistant-authored; the user has not selected their detailed outcomes. + +## Analysis + +Define observable workflow/reliability gates, developer validation with synthetic data, recruitment and onboarding, feedback collection and decisions for broader availability. This is separate from the optional per-practice guided test: do not turn it into a mandatory onboarding step. Country selection and applicable deployment/privacy/safety requirements must be resolved before live patient use. + +## Affected components and boundaries + +Beta scope, Workflow validation, Feedback, Release readiness. The relevant accepted decisions are linked in metadata. A captured item neither changes their confirmed outcomes nor authorizes implementing extra scope. + +## Reproduction or motivating example + +Not a bug report. Use the corresponding confirmed patient/staff journey and synthetic examples to expose missing rules, including exception/failure paths, before choosing the detail. + +## Options and proposed next action + +Open a focused design/grilling session, read the related decisions, collect necessary facts, compare the unresolved options and record explicit choices with acceptance examples. Assign an owner and priority when scheduling this work. + +## Dependencies and revisit trigger + +Before inviting real beta practices or claiming readiness for broader advertising. Related decisions and existing follow-ups are linked above; no due date, owner or numeric policy is invented. + +## Acceptance and verification + +Record beta acceptance criteria, evidence owners and feedback/exit process. Validate the accepted actors and appointment lifecycle, source-labelled profiles, access boundaries, honest notification states and human handoff. Numerical targets come from evidence or explicit decisions rather than invented baselines. + +## Resolution + +Pending. The deferral is accepted; the detailed choices and implementation are not complete. + +## Extra notes and history + +- 2026-10-15T15:54:26Z — Created from the user-approved Q47 deferral; no external outreach, integration changes or application implementation occurred. diff --git a/.planning/follow-ups/20261015T155426Z-define-detailed-booking-policies/follow-up.md b/.planning/follow-ups/20261015T155426Z-define-detailed-booking-policies/follow-up.md new file mode 100644 index 0000000..4e3b20c --- /dev/null +++ b/.planning/follow-ups/20261015T155426Z-define-detailed-booking-policies/follow-up.md @@ -0,0 +1,106 @@ +--- +{ + "schema_version": 1, + "id": "FU-20261015T155426Z-define-detailed-booking-policies", + "title": "Define detailed booking and rescheduling policies", + "kind": "question", + "status": "captured", + "created_at": "2026-10-15T15:54:26Z", + "updated_at": "2026-10-15T15:54:26Z", + "observed_at": null, + "reported_by": "assistant; deferral explicitly accepted by user in Q47", + "owner": null, + "priority": null, + "severity": null, + "origin": { + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "decision": ".planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "pr_url": "https://github.com/codeonym-org/medora/pull/4", + "conversation_reference": "Round 12: q47: ok; preceding Q47 proposed focused details", + "file_or_component": "Booking policy detail", + "revision": null + }, + "affected_components": [ + "Scheduling rules", + "Reservations", + "Rescheduling", + "Cancellation" + ], + "related_decisions": [ + ".planning/decisions/20261015T085738Z-3/D010-provisional-reservation-policy.md", + ".planning/decisions/20261015T085738Z-3/D014-review-deadline-outside-working-hours.md", + ".planning/decisions/20261015T085738Z-3/D032-first-increment-appointment-lifecycle.md", + ".planning/decisions/20261015T085738Z-3/D035-verified-patient-cancellation.md", + ".planning/decisions/20261015T085738Z-3/D037-keep-original-during-rescheduling.md", + ".planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md" + ], + "dependencies": [ + ".planning/decisions/20261015T085738Z-3/scope-review.md" + ], + "related_follow_ups": [], + "duplicate_of": null, + "tracking_issue": null, + "revisit": { + "trigger": "Before implementing the affected scheduling policies or activating them for a practice", + "due_at": null + }, + "resolution": { + "resolved_at": null, + "outcome": null, + "evidence": [] + } +} +--- + +# Summary + +Define detailed booking and rescheduling policies. Preserve the accepted high-level behavior while resolving the remaining detailed choices in a focused session. + +## Why — motivation and impact + +The broad product interview settled the capability and workflow direction, but the details below are not yet decided. The user explicitly accepted Q47 deferral so these choices remain discoverable and block affected implementation/use rather than becoming silent assumptions. + +## When and where — discovery context + +Captured 2026-10-15T15:54:26Z from the product discovery session linked above. The original user-message timestamp is unavailable. The active task was consolidating the product foundation; the detailed branch is deferred with user agreement. + +## Original observation or request + +Q47 asked to capture focused policy/access/communication/profile/beta details before affected implementation/use. The actual user reply was: + +> q47: ok + +The analysis and suggested next steps below are assistant-authored; the user has not selected their detailed outcomes. + +## Analysis + +Durations by appointment type, buffers, booking notice, review/cutoff values, replacement-offer expiry, concurrent holds, original-to-replacement transition and exception/failure behavior remain unspecified. + +## Affected components and boundaries + +Scheduling rules, Reservations, Rescheduling, Cancellation. The relevant accepted decisions are linked in metadata. A captured item neither changes their confirmed outcomes nor authorizes implementing extra scope. + +## Reproduction or motivating example + +Not a bug report. Use the corresponding confirmed patient/staff journey and synthetic examples to expose missing rules, including exception/failure paths, before choosing the detail. + +## Options and proposed next action + +Open a focused design/grilling session, read the related decisions, collect necessary facts, compare the unresolved options and record explicit choices with acceptance examples. Assign an owner and priority when scheduling this work. + +## Dependencies and revisit trigger + +Before implementing the affected scheduling policies or activating them for a practice. Related decisions and existing follow-ups are linked above; no due date, owner or numeric policy is invented. + +## Acceptance and verification + +A decision-backed policy matrix covers working hours/timezone, required configuration, expirations, cancellation/rescheduling outcomes and failed transitions; observable acceptance cases are linked. Values are configurable and are not guessed from this record. + +## Resolution + +Pending. The deferral is accepted; the detailed choices and implementation are not complete. + +## Extra notes and history + +- 2026-10-15T15:54:26Z — Created from the user-approved Q47 deferral; no external outreach, integration changes or application implementation occurred. diff --git a/.planning/follow-ups/20261015T155426Z-define-handoff-and-notification-workflows/follow-up.md b/.planning/follow-ups/20261015T155426Z-define-handoff-and-notification-workflows/follow-up.md new file mode 100644 index 0000000..9f8bede --- /dev/null +++ b/.planning/follow-ups/20261015T155426Z-define-handoff-and-notification-workflows/follow-up.md @@ -0,0 +1,110 @@ +--- +{ + "schema_version": 1, + "id": "FU-20261015T155426Z-define-handoff-and-notification-workflows", + "title": "Define handoff, group and notification workflows", + "kind": "question", + "status": "captured", + "created_at": "2026-10-15T15:54:26Z", + "updated_at": "2026-10-15T15:54:26Z", + "observed_at": null, + "reported_by": "assistant; deferral explicitly accepted by user in Q47", + "owner": null, + "priority": null, + "severity": null, + "origin": { + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "decision": ".planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "pr_url": "https://github.com/codeonym-org/medora/pull/4", + "conversation_reference": "Round 12: q47: ok; preceding Q47 proposed focused details", + "file_or_component": "Communication and handoff", + "revision": null + }, + "affected_components": [ + "Staff handoff", + "Optional groups", + "Agent invocation", + "Delivery failures" + ], + "related_decisions": [ + ".planning/decisions/20261015T085738Z-3/D021-staff-takeover-of-patient-chat.md", + ".planning/decisions/20261015T085738Z-3/D022-optional-patient-group-handoff.md", + ".planning/decisions/20261015T085738Z-3/D023-handoff-staff-assignment.md", + ".planning/decisions/20261015T085738Z-3/D024-agent-context-during-human-handoff.md", + ".planning/decisions/20261015T085738Z-3/D028-notification-failure-after-confirmation.md", + ".planning/decisions/20261015T085738Z-3/D036-default-staff-unavailable.md", + ".planning/decisions/20261015T085738Z-3/D038-optional-group-release-timing.md", + ".planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md" + ], + "dependencies": [ + ".planning/decisions/20261015T085738Z-3/scope-review.md" + ], + "related_follow_ups": [ + ".planning/follow-ups/20261015T142428Z-validate-whatsapp-linked-line-onboarding/follow-up.md" + ], + "duplicate_of": null, + "tracking_issue": null, + "revisit": { + "trigger": "Before implementing or enabling the corresponding handoff, group or delivery-failure flows", + "due_at": null + }, + "resolution": { + "resolved_at": null, + "outcome": null, + "evidence": [] + } +} +--- + +# Summary + +Define handoff, group and notification workflows. Preserve the accepted high-level behavior while resolving the remaining detailed choices in a focused session. + +## Why — motivation and impact + +The broad product interview settled the capability and workflow direction, but the details below are not yet decided. The user explicitly accepted Q47 deferral so these choices remain discoverable and block affected implementation/use rather than becoming silent assumptions. + +## When and where — discovery context + +Captured 2026-10-15T15:54:26Z from the product discovery session linked above. The original user-message timestamp is unavailable. The active task was consolidating the product foundation; the detailed branch is deferred with user agreement. + +## Original observation or request + +Q47 asked to capture focused policy/access/communication/profile/beta details before affected implementation/use. The actual user reply was: + +> q47: ok + +The analysis and suggested next steps below are assistant-authored; the user has not selected their detailed outcomes. + +## Analysis + +Specify group invitation/join/lifecycle, patient/contact membership, human/agent control transfer, invocation meaning, default/backup staff availability and reassignment, notification retry bounds, unresolved delivery escalation and observable patient statuses. Distinguish routine administrative handoff from the established urgent-review safety workflow. + +## Affected components and boundaries + +Staff handoff, Optional groups, Agent invocation, Delivery failures. The relevant accepted decisions are linked in metadata. A captured item neither changes their confirmed outcomes nor authorizes implementing extra scope. + +## Reproduction or motivating example + +Not a bug report. Use the corresponding confirmed patient/staff journey and synthetic examples to expose missing rules, including exception/failure paths, before choosing the detail. + +## Options and proposed next action + +Open a focused design/grilling session, read the related decisions, collect necessary facts, compare the unresolved options and record explicit choices with acceptance examples. Assign an owner and priority when scheduling this work. + +## Dependencies and revisit trigger + +Before implementing or enabling the corresponding handoff, group or delivery-failure flows. Related decisions and existing follow-ups are linked above; no due date, owner or numeric policy is invented. + +## Acceptance and verification + +A state/ownership description covers normal operation, waiting, reassignment, return to agent, invite refusal/failure and delivery failure. Group use remains optional and conditional on the separate official-capability verification; invocation never independently authorizes record changes. + +## Resolution + +Pending. The deferral is accepted; the detailed choices and implementation are not complete. + +## Extra notes and history + +- 2026-10-15T15:54:26Z — Created from the user-approved Q47 deferral; no external outreach, integration changes or application implementation occurred. diff --git a/.planning/follow-ups/20261015T155426Z-define-identity-permissions-and-sharing/follow-up.md b/.planning/follow-ups/20261015T155426Z-define-identity-permissions-and-sharing/follow-up.md new file mode 100644 index 0000000..aa48d6a --- /dev/null +++ b/.planning/follow-ups/20261015T155426Z-define-identity-permissions-and-sharing/follow-up.md @@ -0,0 +1,109 @@ +--- +{ + "schema_version": 1, + "id": "FU-20261015T155426Z-define-identity-permissions-and-sharing", + "title": "Define identity, permissions and sharing access rules", + "kind": "question", + "status": "captured", + "created_at": "2026-10-15T15:54:26Z", + "updated_at": "2026-10-15T15:54:26Z", + "observed_at": null, + "reported_by": "assistant; deferral explicitly accepted by user in Q47", + "owner": null, + "priority": null, + "severity": null, + "origin": { + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "decision": ".planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "pr_url": "https://github.com/codeonym-org/medora/pull/4", + "conversation_reference": "Round 12: q47: ok; preceding Q47 proposed focused details", + "file_or_component": "Identity and permissions", + "revision": null + }, + "affected_components": [ + "Verification", + "Patient access", + "Practice roles", + "Staff sharing" + ], + "related_decisions": [ + ".planning/decisions/20261015T085738Z-3/D001-first-practice.md", + ".planning/decisions/20261015T085738Z-3/D012-conversation-sharing-scope.md", + ".planning/decisions/20261015T085738Z-3/D016-booking-for-someone-else.md", + ".planning/decisions/20261015T085738Z-3/D019-contact-with-multiple-patient-profiles.md", + ".planning/decisions/20261015T085738Z-3/D029-first-contact-existing-record-access.md", + ".planning/decisions/20261015T085738Z-3/D034-practice-configuration-ownership.md", + ".planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md" + ], + "dependencies": [ + ".planning/decisions/20261015T085738Z-3/scope-review.md" + ], + "related_follow_ups": [ + ".planning/follow-ups/20261015T121349Z-choose-beta-operating-countries/follow-up.md" + ], + "duplicate_of": null, + "tracking_issue": null, + "revisit": { + "trigger": "Before enabling affected record access, membership administration, sharing or booking changes", + "due_at": null + }, + "resolution": { + "resolved_at": null, + "outcome": null, + "evidence": [] + } +} +--- + +# Summary + +Define identity, permissions and sharing access rules. Preserve the accepted high-level behavior while resolving the remaining detailed choices in a focused session. + +## Why — motivation and impact + +The broad product interview settled the capability and workflow direction, but the details below are not yet decided. The user explicitly accepted Q47 deferral so these choices remain discoverable and block affected implementation/use rather than becoming silent assumptions. + +## When and where — discovery context + +Captured 2026-10-15T15:54:26Z from the product discovery session linked above. The original user-message timestamp is unavailable. The active task was consolidating the product foundation; the detailed branch is deferred with user agreement. + +## Original observation or request + +Q47 asked to capture focused policy/access/communication/profile/beta details before affected implementation/use. The actual user reply was: + +> q47: ok + +The analysis and suggested next steps below are assistant-authored; the user has not selected their detailed outcomes. + +## Analysis + +Resolve identity evidence, representative/caregiver access, verification lifecycle, role combinations, Owner/Admin versus clinical access, tenant boundaries, sharing revocation and audit behavior. Carry the original privacy/consent/retention and correction/export/deletion requirements into the related design before real patient use. + +## Affected components and boundaries + +Verification, Patient access, Practice roles, Staff sharing. The relevant accepted decisions are linked in metadata. A captured item neither changes their confirmed outcomes nor authorizes implementing extra scope. + +## Reproduction or motivating example + +Not a bug report. Use the corresponding confirmed patient/staff journey and synthetic examples to expose missing rules, including exception/failure paths, before choosing the detail. + +## Options and proposed next action + +Open a focused design/grilling session, read the related decisions, collect necessary facts, compare the unresolved options and record explicit choices with acceptance examples. Assign an owner and priority when scheduling this work. + +## Dependencies and revisit trigger + +Before enabling affected record access, membership administration, sharing or booking changes. Related decisions and existing follow-ups are linked above; no due date, owner or numeric policy is invented. + +## Acceptance and verification + +An explicit permission/verification matrix defines allowed and denied cases, uncertainty escalation and access changes. Sharing/revocation and representative cases have observable acceptance criteria; market-dependent privacy requirements link to beta geography work. + +## Resolution + +Pending. The deferral is accepted; the detailed choices and implementation are not complete. + +## Extra notes and history + +- 2026-10-15T15:54:26Z — Created from the user-approved Q47 deferral; no external outreach, integration changes or application implementation occurred. diff --git a/.planning/follow-ups/20261015T155426Z-define-profile-fields-and-intake-details/follow-up.md b/.planning/follow-ups/20261015T155426Z-define-profile-fields-and-intake-details/follow-up.md new file mode 100644 index 0000000..bfec6a2 --- /dev/null +++ b/.planning/follow-ups/20261015T155426Z-define-profile-fields-and-intake-details/follow-up.md @@ -0,0 +1,105 @@ +--- +{ + "schema_version": 1, + "id": "FU-20261015T155426Z-define-profile-fields-and-intake-details", + "title": "Define profile, intake and correction details", + "kind": "question", + "status": "captured", + "created_at": "2026-10-15T15:54:26Z", + "updated_at": "2026-10-15T15:54:26Z", + "observed_at": null, + "reported_by": "assistant; deferral explicitly accepted by user in Q47", + "owner": null, + "priority": null, + "severity": null, + "origin": { + "session": ".planning/decisions/20261015T085738Z-3/session.md", + "decision": ".planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md", + "issue_url": "https://github.com/codeonym-org/medora/issues/3", + "pr_url": "https://github.com/codeonym-org/medora/pull/4", + "conversation_reference": "Round 12: q47: ok; preceding Q47 proposed focused details", + "file_or_component": "Profile detail", + "revision": null + }, + "affected_components": [ + "Patient profiles", + "Intake templates", + "Provenance", + "Correction review" + ], + "related_decisions": [ + ".planning/decisions/20261015T085738Z-3/D007-basic-patient-profile.md", + ".planning/decisions/20261015T085738Z-3/D017-optional-conversational-intake.md", + ".planning/decisions/20261015T085738Z-3/D027-approved-practice-information.md", + ".planning/decisions/20261015T085738Z-3/D033-intake-template-and-profile-review.md", + ".planning/decisions/20261015T085738Z-3/D039-focused-design-followups.md" + ], + "dependencies": [ + ".planning/decisions/20261015T085738Z-3/scope-review.md" + ], + "related_follow_ups": [], + "duplicate_of": null, + "tracking_issue": null, + "revisit": { + "trigger": "Before implementing affected profile/intake behavior or collecting real patient intake", + "due_at": null + }, + "resolution": { + "resolved_at": null, + "outcome": null, + "evidence": [] + } +} +--- + +# Summary + +Define profile, intake and correction details. Preserve the accepted high-level behavior while resolving the remaining detailed choices in a focused session. + +## Why — motivation and impact + +The broad product interview settled the capability and workflow direction, but the details below are not yet decided. The user explicitly accepted Q47 deferral so these choices remain discoverable and block affected implementation/use rather than becoming silent assumptions. + +## When and where — discovery context + +Captured 2026-10-15T15:54:26Z from the product discovery session linked above. The original user-message timestamp is unavailable. The active task was consolidating the product foundation; the detailed branch is deferred with user agreement. + +## Original observation or request + +Q47 asked to capture focused policy/access/communication/profile/beta details before affected implementation/use. The actual user reply was: + +> q47: ok + +The analysis and suggested next steps below are assistant-authored; the user has not selected their detailed outcomes. + +## Analysis + +Define minimum identity/contact fields, approved appointment-specific intake, optionality, source/timestamp labels, summary limits, corrections and original-text preservation, missing/conflicting answers and authorized review presentation. The starting profile is administrative, not a full medical-record feature set. + +## Affected components and boundaries + +Patient profiles, Intake templates, Provenance, Correction review. The relevant accepted decisions are linked in metadata. A captured item neither changes their confirmed outcomes nor authorizes implementing extra scope. + +## Reproduction or motivating example + +Not a bug report. Use the corresponding confirmed patient/staff journey and synthetic examples to expose missing rules, including exception/failure paths, before choosing the detail. + +## Options and proposed next action + +Open a focused design/grilling session, read the related decisions, collect necessary facts, compare the unresolved options and record explicit choices with acceptance examples. Assign an owner and priority when scheduling this work. + +## Dependencies and revisit trigger + +Before implementing affected profile/intake behavior or collecting real patient intake. Related decisions and existing follow-ups are linked above; no due date, owner or numeric policy is invented. + +## Acceptance and verification + +A field/template and correction specification links to doctor approval, minimal collection, source attribution, skip behavior and contradiction handling. Synthetic examples demonstrate faithful summaries without invented clinical facts. + +## Resolution + +Pending. The deferral is accepted; the detailed choices and implementation are not complete. + +## Extra notes and history + +- 2026-10-15T15:54:26Z — Created from the user-approved Q47 deferral; no external outreach, integration changes or application implementation occurred. diff --git a/.planning/follow-ups/README.md b/.planning/follow-ups/README.md new file mode 100644 index 0000000..d8239a4 --- /dev/null +++ b/.planning/follow-ups/README.md @@ -0,0 +1,5 @@ +# Follow-ups + +Store each captured item in `/follow-up.md` using the [follow-up schema](../templates/follow-up.md). + +Read the naming, capture, triage, and closure rules in [the planning instructions](../README.md). Index records there so unrelated discoveries remain discoverable across sessions. No follow-up is implied by this empty collection. diff --git a/.planning/templates/decision.md b/.planning/templates/decision.md new file mode 100644 index 0000000..941e41e --- /dev/null +++ b/.planning/templates/decision.md @@ -0,0 +1,67 @@ +--- +schema_version: 1 +id: "/D001" +session: "" +title: "" +status: unanswered +round: 1 +created_at: null +updated_at: null +asked_at: null +answered_at: null +confirmed_at: null +decision_owner: user +recorded_by: assistant +issue_url: null +predecessors: [] +related_decisions: [] +supersedes: [] +superseded_by: [] +affected_components: [] +follow_ups: [] +sources: [] +--- + +# Context — why ask this? + +The uncertainty, trigger, current situation, and consequence of leaving it unresolved. + +## Predecessor decisions + +Link each prerequisite and explain how its accepted outcome constrains this question. State explicitly if this is a root decision. + +## Question + +Exact question presented to the user, including choices and relevant framing. + +## Recommendation and alternatives + +What the assistant recommended, why, alternatives considered, and their tradeoffs. This section is not evidence of user acceptance. + +## User reply — original words + +For each exchange, record timestamp if known, message reference, and a blockquote of the relevant actual reply. Retain corrections and partial replies. If unanswered: pending; do not manufacture a quote. + +## Interpretation + +The assistant's reading of the reply, what it implies, what it does not establish, uncertainties, and clarifications still required. + +## Decision and rationale + +The confirmed choice, its scope, and the user's reason if given. Attribute any inferred rationale to the assistant. If unsettled: pending. + +## Consequences and affected components + +Product/workflow implications, tradeoffs, affected capabilities, and downstream questions this unlocks or invalidates. Component names may be product capabilities; no technical stack is required. + +## Assumptions, evidence, and open questions + +Separate confirmed facts from hypotheses. Include sources and missing evidence. Explain when the choice should be revisited and whether it is reversible. + +## Extra notes and follow-ups + +Relevant examples, edge cases, dissent, and links to durable follow-ups. State none if applicable. + +## History + +Timestamp, actor, exchange/change, reason, and any superseded or reopened downstream decisions. diff --git a/.planning/templates/follow-up.md b/.planning/templates/follow-up.md new file mode 100644 index 0000000..06df290 --- /dev/null +++ b/.planning/templates/follow-up.md @@ -0,0 +1,83 @@ +--- +schema_version: 1 +id: "FU-" +title: "" +kind: question +status: captured +created_at: null +updated_at: null +observed_at: null +reported_by: null +owner: null +priority: null +severity: null +origin: + session: null + decision: null + issue_url: null + pr_url: null + conversation_reference: null + file_or_component: null + revision: null +affected_components: [] +related_decisions: [] +dependencies: [] +related_follow_ups: [] +duplicate_of: null +tracking_issue: null +revisit: + trigger: null + due_at: null +resolution: + resolved_at: null + outcome: null + evidence: [] +--- + +# Summary + +The idea, defect, uncertainty, or deferred task in one concise paragraph. + +## Why — motivation and impact + +Why it matters, affected users/workflows, cost of ignoring it, and rationale for priority/severity if assigned. + +## When and where — discovery context + +What task was underway, the triggering event or conversation, when it happened if known, and where the observation can be located again. Explain why it is outside the current scope. + +## Original observation or request + +Quote relevant user wording when available. Otherwise attribute the observation to the assistant. Label redactions explicitly. + +## Analysis + +Observed facts, reported facts, hypotheses, supporting/contradicting evidence, uncertainties, and suspected causes. Distinguish inference from established findings. + +## Affected components and boundaries + +Product capabilities or code components affected, related workflows, external dependencies, and what appears unaffected. Mark unknown scope explicitly. + +## Reproduction or motivating example + +For bugs: conditions, synthetic steps, expected versus actual behavior, and frequency. For ideas: a concrete scenario. Otherwise explain why this is not applicable. + +## Options and proposed next action + +Potential approaches and tradeoffs, smallest useful next step, owner if known, and any decision or authorization still needed. + +## Dependencies and revisit trigger + +Blocking decisions/work, related records, and the event or date that should bring this back into scope. Use unknown where not yet established. + +## Acceptance and verification + +Observable completion criteria and how they will be checked. For research/questions, define the evidence or decision needed. + +## Resolution + +Outcome, links to implementing work or evidence, completion date, and remaining limitations. For dismissal, explain why; for duplicates, link the canonical record. Until resolved: pending. + +## Extra notes and history + +Timestamped updates, corrections, status transitions and their rationale, and supporting evidence links. diff --git a/.planning/templates/session.md b/.planning/templates/session.md new file mode 100644 index 0000000..00e59f2 --- /dev/null +++ b/.planning/templates/session.md @@ -0,0 +1,62 @@ +--- +schema_version: 1 +id: "" +title: "" +status: active +created_at: null +updated_at: null +repository: codeonym-org/medora +issue_number: null +issue_url: null +participants: [] +facilitator: assistant +origin: + conversation_url: null + message_reference: null + related_task: null +predecessor_sessions: [] +supersedes: [] +superseded_by: [] +related_follow_ups: [] +--- + +# Purpose and context + +Why this interview is happening, the problem it should clarify, and why now. + +## Scope and constraints + +In scope, out of scope, and already confirmed constraints with sources. + +## Decision tree + +Root decisions and the branches depending on each. Distinguish dependencies from merely related questions; record blockers without inventing answers. + +## Decision index and rounds + +| ID / link | Round | Question | Predecessors | Status | Outcome | +| --- | --- | --- | --- | --- | --- | + +## Current frontier + +Questions eligible to ask now and questions awaiting replies. Give the round number. + +## Unresolved or deferred branches + +What remains, why it is unresolved, and the prerequisite or revisit trigger. Link captured follow-ups when relevant. + +## Shared understanding + +Summary of confirmed decisions and explicit unresolved assumptions. Recommendations are not decisions. + +## Final user confirmation + +Timestamp, message reference, exact reply, and what scope was confirmed. Until supplied: pending. + +## Related follow-ups and work + +Links to follow-up records, issues, PRs, and relevant documents. + +## History + +Chronological entries with timestamp, actor, change, and reason. Preserve earlier decisions and confirmations. diff --git a/AGENTS.md b/AGENTS.md index 440371b..93a4300 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,9 +1,19 @@ # Medora — Agent Guidance -Medora is an AI medical secretary for doctors and clinics. It coordinates appointments, collects preliminary patient information, and prepares consultation briefings. The doctor retains control over clinical decisions and practice policies. +Medora is a practice-management platform for doctors and clinics, enhanced with integrated AI medical-secretary agents. It coordinates appointments, collects preliminary patient information, and prepares consultation briefings. The doctor retains control over clinical decisions and practice policies. Practice actors include Owner/Admin, Doctor, Receptionist and Patient; keep administrative authority practice-scoped and distinct from clinical access. Before planning or implementing product behavior, read [docs/product-vision.md](docs/product-vision.md) for workflows, scope, and acceptance requirements. +The core patient experience is natural conversation with the WhatsApp agent, including booking and appointment inquiries. Medora attaches to a practice-linked external communication line (WhatsApp only initially); keep the communication contact distinct from the patient being booked. Staff have functional calendar, request-review and patient-profile interfaces alongside private assistant conversations. Patient requests create provisional reservations pending staff review; communicate confirmation only after approval and successful backend execution. See the planning session for unresolved workflow details. + +## Planning memory + +- For every grilling session, create or resume `.planning/decisions//` and maintain its session index and individual decision records. Before interviewing, read [.planning/README.md](.planning/README.md) and relevant predecessor decisions. Follow its schemas and lifecycle rules. +- Record each question, its context and dependencies, the user's actual reply, and your separate interpretation. Save answers before asking the next round; preserve revisions and distinguish confirmed decisions from recommendations and unresolved assumptions. +- Capture unrelated discoveries and deferred work immediately in `.planning/follow-ups//`, using the follow-up schema. Link them from the originating session, issue, or PR; a PR comment alone is insufficient. Logging a follow-up does not authorize implementing it. +- Before resuming planning or beginning related work, consult the planning index and relevant open follow-ups. Keep records in version control, update their outcomes, and obtain explicit confirmation of shared understanding before implementing a grilled design. +- These instructions apply to all future Medora sessions. Honor each session's declared scope and exclusions. + ## Working in this repository - Inspect the current files, dependencies, configuration, and applicable instructions before substantial changes. Use the repository as the source of truth for implementation details. diff --git a/docs/product-vision.md b/docs/product-vision.md index 3ad0d54..2b234bb 100644 --- a/docs/product-vision.md +++ b/docs/product-vision.md @@ -2,12 +2,32 @@ **Your practice, thoughtfully organized.** -Medora is an AI-powered medical secretary that helps doctors manage daily practice, coordinate appointments, highlight requests needing attention, and prepare structured patient context before consultations. Its purpose is to reduce administrative work and help doctors spend more time caring for patients. +Medora is a functional practice-management platform enhanced by integrated AI medical-secretary agents. It helps doctors manage daily practice, coordinate appointments, highlight requests needing attention, and prepare structured patient context before consultations. Its purpose is to reduce administrative work and help doctors spend more time caring for patients. The brand is professional, intelligent, calm, proactive, discreet, and human. The intended market is international, with multilingual product support. Medora should feel like a reliable medical office assistant. Product behavior follows the safety, privacy, and execution boundaries in [AGENTS.md](../AGENTS.md). +## Current discovery decisions + +These confirmed choices refine the original roadmap. The [consolidated scope review](../.planning/decisions/20261015T085738Z-3/scope-review.md) is confirmed by the user; detailed follow-ups remain prerequisites to affected implementation/use. The [active product session](../.planning/decisions/20261015T085738Z-3/session.md) preserves their questions, user replies, rationale, and unresolved details. + +- **Patient communication:** Medora connects to a practice-linked line; initially WhatsApp only. A personally used or shared number is a product requirement; supported onboarding modes still need technical evaluation. Patients book and ask appointment questions naturally in chat. +- **Routing and identity:** A line can represent one doctor or a group. Keep the communication contact separate from the patient, support booking for another person, and reuse verified returning contact-patient details. Staff verify uncertain relationships before existing-record access or changes. +- **Language:** Reply in the speaker's language and remember the speaker/contact preference until changed. This is distinct from patient-profile language and the initial UI locales. +- **Booking approval:** Reserve provisionally and exclusively, then obtain authorized doctor/receptionist review. Notify the patient of actual confirmation, rejection, or scheduling changes; never call a reservation confirmed. +- **Reservation expiry:** Count the configured review budget during staffed hours and cap it at a pre-appointment cutoff. Expire at the earlier limit, release the slot, and notify the patient. Exact durations remain practice configuration. +- **Initial appointment lifecycle:** Basic cancellation and rescheduling requests belong in the first beta alongside booking and profiling. A verified patient cancellation executes immediately, releases the slot after successful cancellation and notifies staff. Keep the original appointment until its replacement is approved and accepted, unless the original is explicitly cancelled or unavailable. +- **Replacement times:** Obtain patient agreement to a different time. The patient may decline and cancel when the replacement does not fit their schedule. +- **Profiles and intake:** Begin with administrative identity/contact details, appointment history, patient-reported visit reasons, and short appointment-specific intake. Doctors choose/approve intake questions and authorized staff may correct information with provenance preserved. Gather minimum booking data first; optional intake follows without blocking confirmation merely because nonessential answers are missing. +- **Staff platform:** Direct calendar, review-queue and patient-profile interfaces operate alongside private assistant chat. AI enhances the platform; the initial product is not limited to a conversation screen. +- **Staff conversation:** Private management conversations may share selected read-only messages with named authorized same-practice colleagues, respecting patient-record permissions. +- **Practice activation:** Require essential scheduling/routing/responsible-staff setup; save/resume is supported and a guided test is optional. +- **Human handoff:** Route to a default staff member configured in Medora, with a configured backup and shared authorized queue for unresolved handoffs. One-to-one human handoff is the beta baseline; optional groups can be added for eligible consenting participants once eligibility, invitations and invocation are verified. During human handling, retain authorized context silently and reply on invocation/control return; invocation alone does not authorize record changes. Native tag behavior and group lifecycle remain unresolved. +- **Schedule and practice information:** Staff maintain real availability in Medora initially; external calendar sync comes later. Answer approved practical information such as hours, address, fees and preparation, escalating missing information to staff. +- **Delivery failures:** Keep a successfully confirmed appointment even if notification delivery fails; surface the failure to staff and retry under policy. Do not claim the patient was informed without evidence. + ## Users and control +- **Practice Owner/Admin** manages practice administration, including staff invitations, permissions and linked lines. This user-requested account updates the earlier three-operational-role framing; exact clinical-data permissions and role combinations remain to be designed. - **Doctors** manage availability, appointments, practice policies, review queues, and patient preparation. They retain authority over clinical decisions and required approvals. - **Patients** request, reschedule, and cancel appointments; communicate preferences and visit reasons; complete relevant intake; and receive confirmed next steps and approved instructions. - **Authorized clinic staff**, when supported, coordinate care administration on behalf of doctors within role-specific permissions. @@ -53,7 +73,7 @@ Practice settings cover working hours, appointment durations, unavailable period ## Essential workflows -1. **Patient booking:** identify practitioner and appointment type; resolve missing date and timezone details; retrieve availability; offer suitable slots; obtain the patient's selection and minimum required information; complete required confirmation; create the booking; report success only after persistence succeeds; offer configured intake. +1. **Patient booking:** converse through WhatsApp; identify practitioner and appointment type; resolve missing date and timezone details; retrieve availability; offer suitable slots; obtain the patient's selection and minimum required information; create a provisional reservation and communicate its pending status; route it to staff; communicate confirmation, rejection, or scheduling changes only after the relevant operation succeeds; collect configured intake conversationally. Apply the confirmed exclusive-hold, expiry, staff-approval, and replacement-time agreement rules; exact deadline behavior and notification failures remain under discussion. 2. **Potentially urgent concern:** gather only appropriate limited clarification; apply the approved escalation protocol; provide emergency guidance without routine scheduling delays when triggered; route clinical review requests to a human; record review status and communicate confirmed next steps. 3. **Doctor's morning:** retrieve the authorized schedule; summarize appointments, pending reviews, incomplete intake, cancellations, conflicts, and changes; provide upcoming patient briefings and actionable administrative tasks. 4. **Cancellation:** identify the appointment; verify identity and authorization through the practice's approved process; explain applicable policy; obtain required confirmation; cancel; communicate success; assess eligible waiting-list candidates for the released slot; update records.