skills/ziwei-timing/references/request-planning.md

# Plan evidence before checking reuse

## Complete demand first

Determine the topic, exact target range(s), comparison candidates, relevant temporal scopes, and calculation timezone from the question before inspecting which charts are available. Do not make allowance or existing chart availability decide what evidence the question needs. If the user asks for a whole period or all candidate windows, a convenient sample cannot stand in for the full request.

Then inventory successful, complete results available in this conversation. Reuse requires a matching signed-in account, saved-profile revision, immutable engine policy, calculation timezone, target moment/period and full required coverage. Apply target/timezone matching to the temporal evidence actually needed; shared natal evidence may answer a natal-only question without re-fetching an unrelated period. Use tool metadata already available to establish the match; do not expose identifiers in the reply. A known edit, deletion, changed account or changed residence invalidates incompatible evidence. If compatibility cannot be established, do not assert it is current. A result whose scope/interval covers the required subset can supply that subset, but cannot supply a missing finer layer.

A website deletion handoff or report pauses reuse of prior birth details, setup drafts, confirmation IDs, candidates and chart evidence. Call `get_profile_status` when completion is reported or the user next requests a chart after the handoff. A successful `configured:false` establishes only that no profile is currently saved, not full deletion completion; `configured:true` means a profile remains. A completion report alone triggers no birth-data question, setup or chart fetch. For a chart request, false follows new-user setup without filling history; true requires current chart evidence before interpretation. Handoff, sign-in, user reports and authentication/read/pending errors do not prove deletion or absence. Explicit reuse of earlier inputs requires fresh preview and later confirmation; never restore automatically.

Only fetch the delta. Explaining a star, giving examples, changing reply language or discussing another topic within the same sufficient result does not require a new chart. A year result cannot answer a monthly ranking; a month result cannot answer a best-day/hour request. Determine those new requirements first, then reuse matching shared evidence and fetch the missing supported periods/targets. If a tool cannot supply the necessary coverage, describe the limitation precisely; do not present a reduced answer as complete.

## Tool routing

Use `get_timing_context` with a fresh internal opaque `operationId` for each new successful context you need:

| Intended coverage | `target` | Complete scopes |
|---|---|---|
| Now | omit | natal, decadal, age, yearly, monthly, daily, hourly |
| Explicit moment | existing `instant` or `localDateTime` form from the tool schema | same seven scopes |
| Named day / daily overview | one supported instant in the main daily window below | natal through daily for that date's main daily baseline |
| Whole-day state / best time within a day | supported instant targets for all 13 shichen windows below | natal through hourly across the requested day |
| Week / dated multi-day comparison | one main daily target for every requested civil date | natal through daily for every candidate day's main baseline |
| Gregorian month | `{"period":"month","year":2026,"month":8}` | natal, decadal, age, yearly, monthly |
| Gregorian year | `{"period":"year","year":2026}` | natal, decadal, age, yearly |
| Last month | `{"period":"month","relative":"previous"}` | natal, decadal, age, yearly, monthly |
| This year / last year | `{"period":"year","relative":"current"}` / `{"period":"year","relative":"previous"}` | natal, decadal, age, yearly |

Absolute period year is 1900–2100; month is 1–12. Relative and absolute forms are mutually exclusive: never combine `relative` with `year` or `month`. Optional `timeZone` is an IANA identifier; omission uses the saved residence timezone. No `referenceDate`, display timezone, arbitrary range or user/account selector belongs in the period input. Read the exposed schema before calling; if the deployed tool lacks period support, do not substitute a single instant.

For “last month”, “last year” and “this year”, prefer the relative form: the server freezes its clock and resolves the Gregorian period in the saved residence/calculation timezone. Show the returned explicit dates in the answer. Do not hard-code the example year, infer timezone from language, or make an extra billable chart call to discover the clock. A retry with the same operation ID retains its original resolved period even across a boundary. Explicit lunar-period requests need their intended range clarified; the Gregorian period API is not a lunar-month selector.

A successful `timing-period-context` supplies a Gregorian half-open `[startDate, endDateExclusive)` period, its calculation timezone and UTC boundaries, one shared natal chart, and contiguous segments for actual changes in the included layers. Month segments may cross lunar-month/year boundaries; year segments may cross lunar new year. Validate their declared coverage and use each segment for its own dates. Do not treat a middle-of-month snapshot as an entire month or add daily/hourly evidence absent from a period result. For day/week requests, compose the scope-specific evidence below instead of declaring a capability gap.

One complete month or year response consumes one chart-context unit regardless of its internal engine samples or number of segments. Do not make twelve calls for a general annual reading or add a natal call when the response includes natal. A request for twelve detailed monthly readings is a different, wider evidence requirement; do not hide it inside the annual overview or suppress required monthly evidence to save units.

Tool calls and returned segments are different counts. A year call may return two or more changes within that year; all returned segments are already obtained and do not require separate calls. Two year calls can cover a cross-year narrative with three distinct phases when compatible adjacent segments have the same required layers. Merge only after verifying those layers and boundaries, and retain their source coverage; a change in the number of paragraphs never implies an extra fetch.

## Days, whole days and weeks

Resolve relative dates once from the current clock in the saved residence/calculation timezone, and show the actual dates. Use the known timezone from compatible tool metadata or the user's explicit location, never from language. Today/tomorrow already identify a date; a clearly requested whole day already identifies the time range. Interpret an unqualified calendar week as Monday–Sunday and state those dates; if it includes elapsed days, distinguish retrospective comparison from still-available choices. Ask only when a material date, timezone or requested granularity remains unresolved. A vague wedding-date search can ask for the intended week/month; a supplied wedding date should proceed to daily analysis.

Use `localDateTime` plus the resolved IANA `timeZone`; these are existing instant inputs, not a new `period:"day"`, `period:"week"` or batch schema. Each distinct target is a separate call with its own operation ID and one unit on success. Submit multiple supported calls as needed and reuse successful compatible results. No batch endpoint is required; do not stop just because more than one call is needed.

Choose the required granularity:

- **Ordinary daily overview / named date:** for the current standard `default-v1` or `zhongzhou-v1` policy (`horoscopeDivide:normal`, `ageDivide:normal`, `dayDivide:forward`), daily and all higher layers are constant within `[00:00,23:00)` of one local civil date. Fetch one valid representative in that main window, normally the date's `00:30`, and read daily and higher layers for the initial daily interpretation. Describe this as the day's general/main background, not complete 24-hour or hourly coverage. Do not automatically add the 23:00–24:00 window to an ordinary exam, wedding-date, spending or launch-date question. A missing event hour does not block this initial answer: obtain the daily evidence first, explain it, then optionally ask for the actual event time to refine it. The representative calculation time is not the event time. This scope-specific rule follows the pinned engine's date/index dependency, not an assumption that equal samples prove coverage.
- **Explicit late-night coverage:** the same civil date has a separate daily state in `[23:00,24:00)`. Fetch a valid target there (normally `23:30`) when the user includes that window or when a proposed actual time falls in it. If only a specific late-night moment is requested, fetch that moment directly without adding an unneeded main-window call. Keep the late-Zi target on the requested date: the next date's `00:30` can have different daily palace mapping or upper layers.
- **Explicit whole-day state or best time within a day:** fetch a valid representative for every one of the 13 requested-index windows: `[00:00,01:00)`, `[01:00,03:00)`, `[03:00,05:00)`, continuing every two hours through `[21:00,23:00)`, then `[23:00,24:00)`. Ordinary valid representatives are `00:30,01:30,03:30,05:30,07:30,09:30,11:30,13:30,15:30,17:30,19:30,21:30,23:30`. Confirm returned indexes 0–12 and use each hourly layer only for its window. An exam question explicitly asking for the entire day's concentration should proceed through these windows. Do not upgrade an ordinary date-level exam question to 13 hourly calls; start with the daily route above. Do not treat representative calculation times as user-supplied event times.
- **Week or month with ordinary date comparison:** enumerate every requested civil date and obtain its main daily baseline. A full calendar week normally needs seven new calls, one per date; a month-by-day comparison covers all its dates. Say that the comparison concerns each day's main background. Do not automatically double the calls to cover deep-night exceptions or imply these daily results rank every hour. Add the missing late-night/hourly windows only for a request that needs them. The month period API alone cannot rank days, and an explicit week/month must not be silently reduced to two or three candidate dates.

Validate every returned calculation timezone, local date, requested index, profile revision and policy before combining results. Upper-layer changes at month/year boundaries stay attached to their actual civil date. Treat the current policy rule as conditional: if the response has another engine policy/configuration, do not assume these daily windows apply; obtain complete supported hourly evidence or explain the actual unresolved rule. DST may shorten, repeat or remove local clock windows. Use the actual civil-time intervals and explicit disambiguation for repeated instants, skip only demonstrably nonexistent intervals, and report any unresolved interval rather than inventing a time or claiming complete coverage. No evidence outside its documented scope/window can fill a gap.

Answer the user's question with a concise daily comparison or useful grouped time windows, not a dump of 13 charts. Preserve meaningful differences and any late-Zi exception. Do not invent scores or rank a partial set as complete. Absence of a statistically supported effect on exams, chance outcomes or other real-world events still limits the interpretation, even when all chart evidence is available.

## Retries and incomplete results

Same-tool, same-input retries keep the exact opaque operation ID so a successful replay does not charge twice. A new target, changed profile or changed semantic input needs a new operation. Failed/unsupported/incomplete results are not usable evidence. If several required calls partly succeed, preserve and reuse the successful compatible results; report the outstanding gap instead of restarting successful calls or pretending the comparison is complete. A tool-reported quota limit does not justify fabricated evidence or a silently reduced scope.

For quota-related informational links, only a necessary evidence gap blocked by an explicit `USAGE_QUOTA_EXHAUSTED` result permits the skill's one-time website link. The required website action link for a deletion request is a separate route and never requires fetching evidence or checking quota. A known low balance is not a reason to fetch evidence that is already sufficient, check quota again, or add a link to another explanation. Short-window rate limits, engine failures, unsupported coverage, connection errors and setup gaps are different limitations; explain them without a proactive website link. Keep the successful part available for interpretation, label the missing part precisely, and do not imply the website supplies a missing chart or an upgrade.

## Optional follow-up examples

Use these as topic ideas, not a required list. Offer at most one or two questions when useful, in the current or explicitly requested language. Do not fetch evidence just to generate them or promise that every suggested question is free. The user's eventual question determines the evidence requirement before reuse/delta is checked.

- After a broad annual reading:「今年工作上，我可以先調整什麼？」「人際關係有哪些值得留意的地方？」Both can reuse that annual result if its relevant evidence is complete and compatible; do not add daily advice from an annual-only result.
- After a monthly relationship discussion:「這個月可以怎麼溝通得更清楚？」A change from relationships to work can also reuse a complete compatible monthly result; topic change alone does not require another chart.
- If comparison would help:「和去年相比，今年有哪些變化？」Offer it without calling tools. If selected, the two full years are the requirement; reuse any compatible year and obtain only the missing one.
- After a Korean-language explanation, a relevant suggestion could be「이 내용을 일상에서 어떻게 활용할 수 있을까요?」Use the user's language rather than copying a Chinese engine label or the starter's original language.

No suggested-question set requires a website footer. Repeated explanation after a quota block still reuses available evidence without repeating the link. If the user changes scope, plan the new scope honestly instead of steering them toward a purchase.