The same API, a bigger request, run in feature scope.

Scope:          feature
Depth:          Standard (from scope feature)
Guard Policy:   off (from scope feature)
Sensors: on (from scope feature)
Learnings: on (from scope feature)
Summary Confirmation: on (from scope feature)
Plan Approval: on (from scope feature)
Collaborators: off (from scope feature)

I'm bringing in the product manager's view for this first step: framing what Ravi asked for and who it's for.

I've created 8 questions at `aidlc/spaces/default/intents/261016-tenant-overdue-digest/ideation/intent-capture/intent-capture-questions.md`. They confirm what the request means: which of the two asks this work covers, who gets the 7 a.m. email, where the per-tenant limits come from, and what the first version leaves out.

How would you like to answer them?

1. Guide me: we go through each question here
2. I'll edit the file: you fill in the answers in the file yourself
3. Chat: we talk it through and I pull the decisions out of the conversation
4. Other

Reply with a number (or just tell me).

Thanks, Kiran. Here is what I took from your answers:

- **Q1:** this work covers both the per-tenant over-limit flag and the 7 a.m. email of over-limit requests per tenant.
- **Q2:** nurse managers in Utilization Management get the email; reviewers benefit from a correct flag.
- **Q3:** success means the flag matches each request's tenant limit, and an email arrives by 07:00 every morning listing every over-limit request, grouped by tenant, with none missing.
- **Q4:** the trigger is both operational (Ravi noticed the shared limit) and contractual (each tenant's limit comes from its contract, so a wrong flag is a compliance risk).
- **Q5:** the stakeholders are Ravi Menon, the reviewers, the priorauth-api team, whoever owns each tenant's limit and holiday list, and compliance / quality.
- **Q6:** Meena Iyer, tech lead for #prior-auth-platform, decides scope and priority; Ravi influences as the requester.
- **Q7:** one email per tenant, to that tenant's nurse manager(s); the addresses live in configuration.
- **Q8:** this first version leaves out a screen for changing limits, channels other than email, and "about to go over" warnings.

…

# :bulb: Intent Capture & Framing Complete

- **Problem:** the over-limit flag uses one shared limit, but each tenant's limit comes from its contract. Managers also have to open the screen to find overdue work.
- **This work covers:** a flag that uses each tenant's own limit, plus one 7 a.m. email per tenant to that tenant's nurse manager(s), listing every request over its limit.
- **Success:** for every pending request the flag matches its tenant's limit, and the email arrives by 07:00 with every over-limit request and none missing.
- **Decides:** Meena Iyer (tech lead). **Influences:** Ravi Menon (requester).
- **Not in this first version:** a screen for editing limits, channels other than email, and "about to go over" warnings.

| Artifact | Contents |
|----------|----------|
| intent-statement.md | Problem, target customer, 3 success metrics, trigger, scope boundary (2 in, 3 out) |
| stakeholder-map.md | 6 stakeholder groups, decision-maker and influencer, the morning-email requirement |
| intent-capture-questions.md | 8 questions, all answered, summary confirmed |

Before the approval, two quick questions about notes for future runs.

**Which notes from this stage should be kept for next time?** (pick any)
1. Keep none of these
2. "Kiran answered for the group (Ravi Menon and Meena Iyer)" → `project.md ## Corrections` (can be widened to the team)

**Anything to add for next time?**
1. Nothing to add
2. Add a note

Reply with each question's number and your choice (for example `Q1: 1, Q2: 1`), or just tell me.

I saved the note to the project rules (`project.md`, under Corrections).

Intent Capture & Framing is ready for your review: what it produced is in aidlc/spaces/default/intents/261016-tenant-overdue-digest/ideation/intent-capture/.

**Stage:** Intent Capture & Framing
**Review outcome:** Concerns remain for your decision.
**Why now:** First review completed.

**Review artifact:** `aidlc/spaces/default/intents/261016-tenant-overdue-digest/ideation/intent-capture/intent-statement.md`

| ID | Severity | Where | Status |
|---|---|---|---|
| R-01 | Major | intent-statement.md > Target Customer, first... | New |
| R-02 | Minor | intent-statement.md > Success Metrics (Email... | New |
| R-03 | Minor | stakeholder-map.md > Communication Requiremen... | New |
| R-04 | Minor | intent-statement.md > Initial Scope Signal (b... | New |

> R-01 Finding: The bullet says nurse managers "no longer need to open the screen to learn what is overdue". That outcome is Q3 option B, and the human did not select it (Q3 answer is A). Q2 only confirms the current pain. The artifact states an unselected outcome as a goal and cites [Q2].

> R-01 Where: intent-statement.md > Target Customer, first bullet

> R-01 Required action: Reword to the confirmed Q2 pain, for example that nurse managers currently have to open the screen to find overdue work. Or ask a follow-up to confirm the outcome as a success criterion.

> R-02 Finding: The "over-limit" definition is never stated. The request says weekends and each tenant's holidays do not count, but no confirmed [Q] answer carries that rule, so "none missing" is not testable from this artifact. The "07:00" has no time zone. The case of a tenant with no over-limit requests (empty email, or no email) is not addressed.

> R-02 Where: intent-statement.md > Success Metrics (Email timeliness, Email completeness)

> R-02 Required action: Add an Assumptions & Open Questions entry tagged [assumption], or a follow-up Q, covering the age rule, the time zone of 07:00, and the empty-digest behaviour. Requirements analysis can then settle each one.

> R-03 Finding: Q7 chose one email per tenant to that tenant's nurse managers. The requester Ravi Menon (Utilization Management, a cross-tenant role) is not stated as a recipient. His interest row says he "wants the morning email".

> R-03 Where: stakeholder-map.md > Communication Requirements and Decision-Makers

> R-03 Required action: Confirm whether Ravi also receives the emails, or whether he is covered only as a tenant nurse manager. Record the answer as a follow-up Q or an open question.

> R-04 Finding: The boundary entries "limits are set in configuration" and, in the stakeholder map, "addresses live in configuration" are implementation-level detail in an ideation artifact.

> R-04 Where: intent-statement.md > Initial Scope Signal (boundary tables)

> R-04 Required action: Restate them as needs (limits and recipients are maintained without a screen). Leave the mechanism to later stages.

**Decision options:**
- **Approve** - continue with the open findings accepted.
- **Request Changes** - return to the listed artifacts so the required actions can be addressed.

My take: R-01 is a real wording slip on my part. The fix is a one-line rewording back to the pain you confirmed. R-02 and R-03 are details Requirements Analysis will settle anyway: the time zone for 07:00, whether weekends get an email, the empty-email case, and whether Ravi also gets every tenant's email.

**Review:** `aidlc/spaces/default/intents/261016-tenant-overdue-digest/ideation/intent-capture/`

If you approve, the next step is Market Research.

1. Approve: continue to Market Research
2. Request Changes: tell me what to revise

Reply with a number (or just tell me).

I've recorded your change request and added Ravi's copy of every email as a follow-up question in the questions file.

Your answer didn't reach AI-DLC. Please give it once more. If it happens again, type /aidlc --doctor.

**Q9. Does Ravi Menon also receive the morning emails?**
1. Yes: Ravi gets a copy of every tenant's email
2. No: only each tenant's own nurse manager(s) receive it
3. Not yet defined
4. Other

Reply with a number (or just tell me).

I've revised both documents with Meena's four changes:

- **R-01:** the Target Customer line now states the confirmed pain: today managers have to open the screen to find overdue work.
- **R-02:** the age rule, the time zone of 07:00, and the empty-email case are listed as open questions for Requirements Analysis.
- **R-03:** Ravi now receives a copy of every tenant's email, in both the intent statement and the stakeholder map.
- **R-04:** "in configuration" is restated as a need: limits and recipients are maintained by the team without a screen.

One last check before the re-review. Those three open questions are marked as unconfirmed in the documents. Meena asked to leave them for Requirements Analysis, which is option 1.

1. Accept assumptions: keep them as open questions for Requirements Analysis
2. Convert to follow-up questions: answer them now, in this stage
3. Other

Reply with a number (or just tell me).

| ID | Severity | Where | Status |
|---|---|---|---|
| R-01 | Major | intent-statement.md > Target Customer, first... | Resolved (reviewer) |
| R-02 | Minor | intent-statement.md > Success Metrics (Email... | Resolved (reviewer) |
| R-03 | Minor | stakeholder-map.md > Communication Requiremen... | Resolved (reviewer) |
| R-04 | Minor | intent-statement.md > Initial Scope Signal (b... | Resolved (reviewer) |
| R-05 | Minor | intent-statement.md > Initial Scope Signal, "... | New |

> R-05 Finding: The row says limits and recipients are "maintained by the team without one". The Q7 and Q8 answers only say the addresses and limits "live in configuration". They do not say who maintains them or that it is "the team".

> R-05 Where: intent-statement.md > Initial Scope Signal, "Not in this first version" row 1

> R-05 Required action: Say only that no screen is provided and changes are made outside the product. Leave who maintains them to Requirements Analysis as an open question.

…

If you approve, the next step is Scope Definition.

1. Approve: continue to Scope Definition
2. Request Changes: tell me what to revise
3. Add Market Research: run the stage I skipped

Reply with a number (or just tell me).

Answering the way you chose earlier: Chat. Say if you'd rather be guided through them here or edit the file.

The code turned up a few things that affect feasibility:
- The API can't send email or run timed jobs yet.
- Only one tenant has a holiday calendar (`TX-01`), and only for 2026.
- The email will carry health-plan request data out of the system.

The 8 questions are in `aidlc/spaces/default/intents/261016-tenant-overdue-digest/ideation/feasibility/feasibility-questions.md`. Answer in whatever form suits you, as you did last time:

- **Q1. What may the email contain?** A: request ID, tenant, service, received date and age, with no member ID. B: A plus the member ID. C: only a count per tenant and a link to the screen. D: not yet defined, compliance decides.
- **Q2. How can the API send email?** A: an organisation mail relay it may use. B: another team's notification service. C: nothing exists yet. D: not known.
- **Q3. Where does the 7 a.m. list come from?** A: the same live source as the screen, read at send time. B: the nightly export, as of last night. C: not known.
- **Q4. How many tenants today?** A: two, Northside and Lakeview. B: more (please list them, with IDs if you have them). C: not known.
- **Q5. Holiday calendars.** A missing calendar counts holidays as working days, which can wrongly flag a request. A: tenant owners supply 2026 and 2027 calendars for every tenant before go-live. B: accept today's behaviour as a known risk. C: not known.
- **Q6. How does the API run in production?** A: one always-on instance. B: several instances behind a load balancer. C: a platform with its own job scheduler. D: not known.
- **Q7. Timeline.** A: no fixed date. B: a fixed date. C: a freeze or competing priority is coming. D: not known.
- **Q8. A new email library.** A: the framework's standard email library is fine if the plan names it. B: Meena approves first. C: no new libraries, use an internal service. D: not yet defined.

When you're ready to proceed, say **done** and I'll summarize our decisions.

# :test_tube: Feasibility & Constraints Complete

- **Verdict:** feasible, with low-to-moderate risk. Every capability has a confirmed route: the organisation's mail relay, one always-on instance, and the standard mail library. The real risks are data being ready and correct.
- **Biggest risk:** holiday calendars for 2027 must be in place by 1 January 2027, about ten weeks away. Without them, holidays count as working days and requests are flagged wrongly.
- **Other risks:** a stale nightly export, a missed email if the instance is down at 07:00, silent send failures, and Ravi seeing every tenant's requests in his copies (to confirm with compliance).
- **Dependencies:** Lakeview's (`TX-02`) data and limit, both tenants' 2026 and 2027 calendars, how the export is refreshed, the relay settings, and the recipients' addresses.

| Artifact | Contents |
|----------|----------|
| feasibility-assessment.md | Verdict, 6 capabilities rated, risk rating by area |
| constraint-register.md | 3 compliance, 6 technical, 4 organisational, 3 scope constraints |
| raid-log.md | 6 risks, 3 assumptions, 2 issues, 5 dependencies |
| feasibility-questions.md | 8 questions, all answered, summary confirmed |

Two quick questions about notes before the approval:

**Which notes from this stage should be kept for next time?** (pick any)
1. Keep none of these
2. "The specialists were off for this work; compliance input came from the human compliance team" → `project.md ## Corrections`

**Anything to add for next time?**
1. Nothing to add
2. Add a note

Reply with each question's number and your choice (for example `Q1: 1, Q2: 1`), or just tell me.

Answering the way you chose earlier: Chat. Say if you'd rather be guided through them here or edit the file.

Most of the scope is already settled by the intent and feasibility answers, so I have only 4 questions, all about how to slice and protect the first release. They're in `aidlc/spaces/default/intents/261016-tenant-overdue-digest/ideation/scope-definition/scope-definition-questions.md`:

- **Q1. How should the two capabilities ship?**
  - A: together, in one release.
  - B: the per-tenant flag first, then the email. The flag fixes a contractual risk on the screen today.
  - C: the email first.
  - D: decide at delivery planning.
- **Q2. Is getting Lakeview (`TX-02`) set up part of this work?**
  - A: partly. This work adds its limit, calendar and recipients; its request data comes through the export from the data owners.
  - B: fully, including its request data.
  - C: no. This work only has to behave correctly once Lakeview's data and settings exist.
  - D: not yet defined.
- **Q3. Which safeguards are must-haves for the first release?** Pick any:
  - A: the email says which day's data it was built from.
  - B: a failed send is logged and visible.
  - C: a missed 07:00 send goes out late after a restart.
  - D: the API refuses to start when a tenant has no limit or no recipients.
  - E: none beyond the core.
- **Q4. Is any one capability tied to a deadline?**
  - A: no.
  - B: the flag must be live before Lakeview goes live.
  - C: everything before 1 January 2027, when the calendars change year.
  - D: not known.

When you're ready to proceed, say **done** and I'll summarize our decisions.

Credit balance is too low