Save an edit to your draft
update_draftDestructive
Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Save a new version of your draft (state drafted): the whole Markdown, and base_hash, the hash of the version you edited (draft.base_hash from get_status, or your last update_draft's text_hash). Answers in a second or two; the preview rebuilds in the background. It runs no checks: lint_draft the edit first, then check_draft with the id. Refused if the draft changed since base_hash or is open in the browser editor. The engineer may also edit and save it in the draft app: start each edit from a fresh get_status. Never publishes.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The idea id | |
| kind | No | Optional: the draft's kind, which is fixed when it is submitted. Sent, it must match (get_status says it). | post |
| sources | No | New sources, replacing the ones sent before: the engineer's own words, which the fact-check reads a post's claims against, or a case study's numbers are checked against. | |
| base_sha | No | Instead of base_hash: draft.base_sha from get_status, the commit your edit started from | |
| markdown | Yes | The whole post, with its frontmatter | |
| base_hash | No | The hash of the version your edit started from: draft.base_hash from the get_status you edited from, or the text_hash your last update_draft returned. It stays good after that save is committed | |
| post_type | No | The post type, which sets the opening rule and how hard the fact-check reads it. story (the default): work someone at TechFabric did. The opening has TechFabric doing that work by paragraph two, and every claim gets the full fact-check. perspective: a talk or conference the author attended, a conversation with an industry leader, others' work, or our view of what's possible. TechFabric's view by paragraph two ("we think", "we'd", "I believe" count). What a speaker or another company said is attributed in the sentence ("In her demo, ...") and must match what the author provided; forward-looking views need no source. whats-new: a new feature in AI, Databricks or related tech, and how it could help future projects. Open on what changed (its date and source), then our view. Product facts (name, preview or GA, date, what it does) are checked against the vendor's docs or release notes; forward-looking views need no source. personal: the author's own essay or position, in the first person, about where the work or the industry is going and what people should do. Opening and fact-check as perspective, and the only type that may take the memo register: conviction carried as "I believe" and the reader addressed as "you" throughout, up to three bold thesis sentences, one "this is not X" thesis reframe and a closing call to act (other types keep every slop rule, though a perspective opening may still state its view as "we think" or "I believe"). Never for an engineer explaining a feature or their own project. Choose personal only when the engineer writes in their own voice about a position, never for an engineer explaining a feature or their project. Left out, it is story; an explainer is always whats-new. Not for a case study. | |
| first_hand | No | First-hand claims only the engineer can source, which the fact-check flagged first_hand (first_hand_to_confirm): each the sentence exactly as quoted, with what it rests on. Sending it asks the engineer; it never confirms anything on your word. check_draft asks them in their client (an elicitation) where it can, otherwise answers with a question and a one-time confirmation: ask them that question, and only if they say yes, send it back as first_hand_confirmation with the same first_hand. submit_draft and update_draft answer with the question and confirmation too, which come back on check_draft with the id. Never a client's result: a number about a client needs the client's confirmation, as a source. | |
| app_instance | No | The draft app only, never an agent: the view whose own unsaved edits this save is | |
| client_confirmed | No | Only when the engineer tells you they have the client's confirmation to name the client this draft names (its client:, or a client in its text the register doesn't approve). Recorded under the engineer's name with the draft and its text; never send it on your own judgement. It covers naming the client, not results: numbers still need sources. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| next | Yes | ||
| saved | Yes | ||
| steps | No | Where the draft is, step by step (the same steps the progress notifications name): done, active (under way now), pending or failed | |
| saving | No | ||
| status | No | ||
| base_hash | No | ||
| post_type | No | The post type the draft carries (postType in its frontmatter; story when it has none). Not for a case study | |
| text_hash | Yes | The saved text's sha256: the next update_draft's base_hash | |
| first_hand | No | When first_hand was sent: nothing is recorded here. The engineer is asked on check_draft with the id (in their client, where it can ask them), or, for update_draft in a client that can't, this carries the question and a one-time confirmation to hand back on check_draft only after they say yes | |
| next_action | Yes | The one next step. Do what instruction says; call is the tool and the arguments the server already knows | |
| preview_url | No |