[]

Relationship to notte-functions-build. Doctor reuses that skill's two engines - exploration (find the new stable path) and self-test (verify against the contract) - pointed at an existing Function instead of a blank one. It also builds on the base notte-browser skill. Load those for the full command reference.

notte functions show --function-id "{function_id}"

functions list

• it defaults to 10 items per page,
• the API caps

  --page-size

  at 100,
• the CLI prints a bare JSON array and drops the

  has_next

  field, so the only way to know you have reached the end is a page shorter than the page size.

undefined

1. The health contract - read the

   === HEALTH CONTRACT ===

   block and the response model in

   current_function.py

   . This is the explicit target (built Functions carry it).
2. The last good run - the strongest evidence of correct output, when you can get it:
   bash

   # `functions runs` returns the full history by default (--running would
   # narrow it to runs still executing, which is not what you want here).
   notte functions runs --function-id "{function_id}" -o json
   # pick a past run whose result is a valid object, then:
   notte functions run-metadata --function-id "{function_id}" --run-id "{good_run_id}" -o json | jq '.result'

   (

   run-metadata

   's

   result

   is a Python

   repr

   rather than clean JSON - single-quoted and not

   jq

   -parseable, but still readable as evidence of the expected shape.)
   If history is genuinely empty, treat that as uninformative rather than as evidence the Function never worked: fall back to the health contract and the response model, and say in your report that no run history was available.

1. Patch. Re-export the corrected path (

   notte sessions workflow-code --session-id <id>

   ) and merge the changed selectors/endpoint into

   current_function.py

   , or hand-edit using the Python SDK Interop reference. Save as

   repaired_function.py

   . Keep the same

   run(...)

   signature and response model so callers are unaffected.
2. Verify on a throwaway copy. Create a temporary verification Function, capture its ID, and from here on pass

   --function-id "$VERIFY_ID"

   on every command. This keeps testing fully isolated from the live Function:
   Always create your own copy. Never adopt one by name. The id returned by

   notte functions create

   is the only proof of ownership you have. A matching display name is not proof of anything:

   [doctor-verify] {id}

   is predictable, so a concurrent repair of the same Function - or anyone who typed that name - produces the identical label. Adopting it would overwrite work that is not yours, and the later delete would destroy it.
   bash

   LIVE_ID="{function_id}"
   VERIFY_NAME="[doctor-verify] $LIVE_ID"
   
   # Create it. $VERIFY_ID is yours because you just made it.
   VERIFY_ID=$(notte functions create --file repaired_function.py \
     --name "$VERIFY_NAME" -o json | jq -r '.function_id')
   
   # functions run blocks and returns status + result inline:
   notte functions run --function-id "$VERIFY_ID" -o json | jq '{status, result}'

   Iterate with

   notte functions update --function-id "$VERIFY_ID"

   - that id, never a name lookup.
   Strays from an earlier attempt: report, do not touch. If a previous repair was abandoned without cleanup, a copy with the same name may already exist. You cannot prove it is yours, so do not adopt it and do not delete it - list it for the user and let them decide:
   bash

   all_functions --include-deleted \
     | jq -r --arg n "$VERIFY_NAME" --arg mine "$VERIFY_ID" \
         'select(.name == $n and .function_id != $mine)
          | "stray verification copy, not created by this repair: \(.function_id)"'

   Delete the throwaway however this ends. Cleanup is written up in Phase 6 because that is the common path, but it is not conditional on promoting: if verification never passes, or the user declines at the gate, or you abandon the repair, still delete the copy you created, per Phase 6 step 3. Since a later run will not adopt it, an orphan left behind is one a human has to clear.
   Validate the result against the contract using the same loop as build-time: -> notte-functions-build self-test reference (pass

   $VERIFY_ID

   as its target id). Read

   result

   , not

   status

   (

   status

   is

   "closed"

   either way): a JSON object matching the schema is a pass; a string with a

   Traceback

   /

   AssertionError

   is a fail. Iterate with

   notte functions update --function-id "$VERIFY_ID" --file repaired_function.py

   until it passes.

   Alternative isolation: if the Function is shared/forkable,

   notte functions fork --function-id {function_id}

   gives an isolated copy to test on instead of a throwaway. The throwaway-create path above works in all cases, so prefer it unless forking is clearly available.

1. Show the user a diff and a root-cause summary before changing anything live:
   bash

   diff -u current_function.py repaired_function.py

   Summarize plainly, e.g. "Indeed moved the salary field from

   .salary-snippet

   to

   [data-testid=salary]

   ; updated the selector. Verified: 25/25 listings returned salary."
2. On explicit approval, update the live Function:
   bash

   notte functions update --function-id "{function_id}" --file repaired_function.py

3. Clean up the throwaway verification Function. The safety gate is a content check, not the CLI prompt: read the name back, confirm the

   [doctor-verify]

   prefix, and delete only inside the matched branch. That name guard is stronger than the CLI's generic

   [y/N]

   prompt - and since the prompt defaults to No, a non-interactive agent would otherwise see the delete auto-cancel. Pass

   --yes

   only inside the guarded branch (never on an unverified id):
   bash

   NAME=$(notte functions show --function-id "$VERIFY_ID" -o json | jq -r '.name')
   if [ "$NAME" = "$VERIFY_NAME" ]; then
     notte functions delete --function-id "$VERIFY_ID" --yes
   else
     echo "ABORT: $VERIFY_ID is '$NAME', not this repair's throwaway - not deleting"
   fi

   $VERIFY_ID

   is the id your own

   create

   returned, which is what makes this delete safe. The name check is a second belt against a stale or mistyped variable - not the proof of ownership. Never resolve the target by name and delete the result; a matching name says nothing about who made it.
4. Confirm the live Function is healthy, then restore its schedule:
   bash

   notte functions run --function-id "{function_id}" -o json | jq '{status, result}'

   Confirm

   result

   is a valid object (not a

   Traceback

   string) before considering the repair done.

   If the Function writes anything, this run writes again. You already proved the fix on the verification copy, so for a Function that submits a form, makes a purchase, or otherwise mutates state, say so and let the user decide whether to run it live - do not invoke it reflexively.

   The CLI cannot read a cron back, so a cleared schedule is not detectable by inspection. If the Function was scheduled (Phase 1), re-apply the cron you recorded - re-applying the same cron is idempotent:
   bash

   notte functions schedule --function-id "{function_id}" --cron "{recorded cron}"

• Before

  notte functions update

  on the live Function - show the diff + root cause and get explicit approval (Phase 6).
• Before

  notte functions delete

  of any Function - the name guard is the gate: read the target's name back, confirm the

  [doctor-verify]

  prefix, and delete only inside the matched branch. Never delete by an unverified id (

  --yes

  is acceptable only after the name guard has confirmed the target).
• Sensitive site actions during re-exploration (login, form submission) follow the notte-browser security notes.