question: natural-language question (e.g. "10/2 사람인 지원 몇 곳?").
    spec: optional structured QuerySpec; when given, no LLM is used.
    narrate: also write a prose answer with the LLM (it only sees aggregates).
    by: your agent name (optional; kept in the local query log).
    

    view: recent (last n) | warnings (answers that carried warnings) | errors |
          diverging (the same question pattern answered with different SQL — the interpretation moved) |
          path (only questions answered by `path`: fast | cache | llm | structured | entity | none) |
          empty (answers that found nothing — check whether the reading was wrong; with `path`, e.g.
          cache, only those).
    since: only entries asked at or after this time (ISO 8601).
    

    Structured: entity_type + kind (created | updated | status_changed | corrected | retracted)
    + payload, and the target by entity_id or match (field values, e.g. {"platform": "saramin",
    "posting_id": "10000001"}). Reference fields may hold a name (e.g. a company name).
    Free text: text="사람인 10000001 가상테크 열람" — the Keeper structures it.
    at: when it happened (ISO 8601 with offset); defaults to now. at_precision: time | date (only the
    day is known) | unknown. by: your agent name.
    evidence: why you believe it (quote, mail subject...).
    Fields or values the dictionary does not know are stored as given (drafts, queryable at once); the
    reply lists them under `drafts` and may ask under `questions` whether a new name means an existing one.
    New kind of record (entity_type not in list_schemas, kind created): it is stored at once under a new draft
    type. Send schema_draft with it — the schema you suggest: {"description", "keywords", "fields": {name:
    {"type", "description", "enum", "labels", "required", "indexed", "format"}}}; you know best what each field
    means now. The reply carries a proposal under `proposals`: ask the user, and on their yes call
    apply_schema_proposal. If the name looks like an existing type you are asked first (new_type=true confirms).
    Returns status:
      recorded — stored (check `drafts` and `questions`);
      clarify  — nothing stored: the target is ambiguous (several matches), a referenced name (e.g. a
                 company) is unknown or only similar, the record looks like a duplicate, or it contradicts
                 the current state; ask the user and call again;
      rejected — nothing stored: a registered field is violated (required field missing, wrong type, bad
                 date) or the target was looked up by an unregistered field;
      error    — free text could not be structured (no LLM configured or the call failed).
    

    One call = one batch, all or nothing: if any point is invalid nothing is stored and `rejected` says why.
    A point whose key and time are already stored is updated (the batch keeps the previous values).
    source: where the values come from (file, app, "user said"). by: your agent name.
    Returns batch_id and counts (inserted / updated / unchanged); revert_series_batch(batch_id) undoes it.
    

    Never call this on your own initiative. First show the user the proposal from propose_schema (its
    `question`), ask whether to apply it, and call this only after they answer yes. Pass who approved
    (approved_by) and the user's own words (user_answer); both are kept in the schema history.
    descriptions: {field: description} for every field being registered (required).
    labels: {field: {value: [natural-language names]}} for every new enum value (required, e.g.
    {"platform": {"remember": ["리멤버"]}}).
    merges: {draft_field: target_field} to fold look-alike names together (values move with history kept).
    index: fields to index. type_description: a new type's description, if its proposal has none.
    items (dict_... only): the item keys the user picked; default: the proposal's additive items. Items left out
    are not offered again for the same file.
    The data itself was already stored when it was written; this only organizes it.
    

    Without samples: how to organize drafts — fields and enum values that records already use but the
    dictionary has not registered (they are stored and queryable; organizing adds descriptions, labels,
    indexes, and merges look-alike names). Ask the user before apply_schema_proposal.
    With samples and a new entity_type: a first schema draft for a new kind of record.