Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions .agents/skills/marimo-wandb-notebooks/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -109,3 +109,12 @@ Before considering a conversion complete:
[`references/wandb-patterns.md`](references/wandb-patterns.md).
- No unintended generated or runtime files were introduced, and the notebook
and docs do not depend on `.logs/`.
- Opening the notebook and changing unsubmitted controls do not create W&B
objects or other remote side effects.
- Each submission performs its intended remote writes once; re-submission
closes prior runs and avoids duplicate stateful updates where practical.
- Cross-cell consumers of W&B state use explicit result or completion values,
and producers synchronize server-visible state before downstream reads.
- A fresh molab session can authenticate without credentials from the local
computer, and no credential appears in notebook output, run configuration,
logs, or the diff.
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,12 @@ function clean and put its gate or UI wiring in separate cells.
Gate each expensive or externally side-effecting workflow stage once at its
boundary.

Treat an explicit form submission or run-button click as the reader's consent
boundary for remote writes. Label the control with the action it performs and
state what it creates. Opening the notebook, changing an unsubmitted control,
or lazily rendering content must not create a remote object; `mo.lazy()` is not
a substitute for explicit consent.

Keep forms, buttons, widget `.value`, and `mo.stop(...)` in small orchestration
cells rather than mixing them into teaching code.

Expand Down
33 changes: 30 additions & 3 deletions .agents/skills/marimo-wandb-notebooks/references/wandb-patterns.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,16 @@ Use these patterns when a marimo example uses the W&B Python SDK.
## Authentication

- Offer a `mo.ui.text(kind="password")` API-key field.
- When the field is blank, rely on W&B's normal credential resolution
(`WANDB_API_KEY`, W&B settings, or credentials stored by `wandb login`).
- Never display, log, or include the API key in run config.
- Call `wandb.login()` only after the reader explicitly submits the form or
clicks the run button.
- A fresh molab runtime does not inherit credentials from the reader's local
computer. When the submitted key is non-empty, pass it to
`wandb.login(key=...)`. When it is blank, rely on W&B's normal credential
resolution, including `WANDB_API_KEY` from the marimo Secrets panel, W&B
settings, or credentials stored by `wandb login` in the current runtime.
- Never display, log, or include the API key in run config. Do not print the
submitted form value or the full notebook namespace because either can
expose the key.

## Runs And Reruns

Expand All @@ -25,6 +32,26 @@ active across cells, finish any prior active run before starting another one.
- Prefer methods on the active run, such as `run.log()`, `run.log_artifact()`,
and `run.summary`, unless the tutorial intentionally teaches another W&B API
pattern.
- Within one submission, perform each intended remote write once. On
re-submission, clean up any prior active run and make stateful remote updates
idempotent when practical, such as skipping an alias or Registry link that is
already present.

## Ordering Remote Effects

marimo orders cells through name dependencies; it cannot observe mutations to
`wandb.config`, run or Artifact objects, or W&B's remote state.

- If a later cell relies on a W&B write performed by an earlier cell, keep the
ordered transaction in one cell or helper, or return an immutable result or
completion value from the writer and make the consumer depend on it. Sharing
only `wandb`, a run, or an Artifact object does not encode the remote ordering.
- Wait until a write is visible to the server before consuming it. Finish or
synchronize the run, and wait for an Artifact upload when a later step calls
`use_artifact`, queries the Public API, or links the Artifact into Registry.
- When reading data that was just logged, capture a stable run or Artifact path
while it is available, synchronize the producer, and only then issue the
Public API query.

## Entity

Expand Down
Loading