Improve agent notebook project ergonomics

Author: carlos-schrupp

README.md

@@ -208,6 +208,8 @@ Current provider support:
 - OpenAI through `wellplot.agent`
 - OpenAI-compatible endpoints through `provider="openai_compat"` plus
   `base_url=...`
+- local Ollama through `provider="ollama"` with a default
+  `http://localhost:11434/v1` base URL
 
 Recommended credential setup:
 - prefer `OPENAI_API_KEY` in the shell for OpenAI sessions
@@ -218,6 +220,8 @@ Recommended credential setup:
   secret that stays out of version control without editing notebook cells
 - loopback OpenAI-compatible endpoints such as `http://localhost:11434/v1`
   receive an automatic placeholder token when no key is configured
+- `provider="ollama"` is a notebook-facing convenience alias over the same
+  OpenAI-compatible backend and automatically uses the loopback base URL above
 
 The main entry points are:
 - `from wellplot.agent import AuthoringSession`
@@ -230,6 +234,8 @@ The main entry points are:
 Notebook-facing project helpers:
 - `create_project_session(...)` to bootstrap one reusable project-scoped agent session
 - `session.add_data_file(...)` to stage LAS or DLIS sources into the project folder
+- `session.bootstrap_starter(...)` to stage data, configure default draft/render
+  paths, and materialize one starter scaffold in one call
 - `session.create_starter(...)` to generate one starter template/logfile pair from a shipped preset
 - `session.configure_rounds(...)` and `session.configure_paths(...)` to keep later notebook cells short
 
@@ -368,7 +374,7 @@ Current examples:
 - [examples/notebooks/user/agent_las_step_by_step.ipynb](examples/notebooks/user/agent_las_step_by_step.ipynb)
   - credentialed end-user walkthrough that bootstraps a project session,
     stages a user LAS file, generates a reusable starter scaffold through
-    `session.create_starter(...)`, and adds header, remarks, tracks, and
+    `session.bootstrap_starter(...)`, and adds header, remarks, tracks, and
     bindings one step at a time through `wellplot.agent`
   - working first-pass agent workflow: functional, but intentionally less
     curated than the deterministic production notebooks and may still need

docs/site/guides/example-7-agent-las-step-by-step.md

@@ -28,8 +28,7 @@ The flow is:
 The notebook uses these public APIs directly:
 
 - `create_project_session(...)`
-- `session.add_data_file(...)`
-- `session.create_starter(...)`
+- `session.bootstrap_starter(...)`
 - `await session.run(...)`
 - `await session.revise(...)`
 - `await session.render_logfile_to_file(...)`
@@ -80,14 +79,17 @@ That is why it lives in the `user/` notebook set but remains unexecuted in git.
 Start with the default copied LAS file once so the full workflow is known to
 work in your environment.
 
-Then point `session.add_data_file(...)` at your own LAS file so the project
-folder gets a staged `user_input.las` before rerunning from the top.
+Then point `session.bootstrap_starter(...)` at your own LAS file so the project
+folder gets a staged `user_input.las`, refreshed starter files, and the same
+default draft/render targets before rerunning from the top.
 
 The starter scaffold step is intentionally higher level than the YAML-first
 user notebooks. Instead of hand-writing the full template and starter logfile
-schema in the notebook, this walkthrough uses `session.create_starter(...)` to
-materialize the same files from a shipped preset, then shows the generated YAML
-so the user can still inspect what the agent will revise.
+schema in the notebook, this walkthrough uses
+`session.bootstrap_starter(...)` to stage the data source, configure the
+project defaults, materialize the same files from a shipped preset, and then
+show the generated YAML so the user can still inspect what the agent will
+revise.
 
 The safest iteration pattern is:
 

docs/site/guides/examples.md

@@ -100,9 +100,9 @@ The examples are grouped by workflow rather than by isolated feature.
     developer notebook set
 - `examples/notebooks/user/agent_las_step_by_step.ipynb`
   - detailed user walkthrough that bootstraps a reusable project session with
-    `create_project_session(...)`, stages a LAS file, generates a starter
-    scaffold through `session.create_starter(...)`, and adds header, remarks,
-    tracks, and bindings one step at a time through `wellplot.agent`
+    `create_project_session(...)`, stages a LAS file and starter scaffold
+    through `session.bootstrap_starter(...)`, and adds header, remarks, tracks,
+    and bindings one step at a time through `wellplot.agent`
   - manual and credentialed: requires `wellplot[agent,notebook,las]` plus an
     OpenAI API key at runtime
   - working first-pass notebook: expect to tune prompts, model choice, and

docs/site/installation.md

@@ -96,6 +96,8 @@ Current provider support:
 - OpenAI
 - OpenAI-compatible endpoints through `provider="openai_compat"` plus
   `base_url=...`
+- local Ollama through `provider="ollama"` with a default
+  `http://localhost:11434/v1` base URL
 
 Credential guidance:
 
@@ -108,6 +110,8 @@ Credential guidance:
 - for loopback-compatible endpoints such as `http://localhost:11434/v1`,
   `wellplot.agent` injects a placeholder token automatically when no key is
   configured
+- `provider="ollama"` is a notebook-facing convenience alias over the same
+  OpenAI-compatible backend and automatically uses that loopback base URL
 
 ## Verify The Install
 

docs/site/workflows/mcp-workflow.md

@@ -23,6 +23,8 @@ Current `wellplot.agent` provider support:
 - OpenAI
 - OpenAI-compatible endpoints through `provider="openai_compat"` plus
   `base_url=...`
+- local Ollama through `provider="ollama"` with a default
+  `http://localhost:11434/v1` base URL
 
 ## Agent Credentials
 
@@ -49,6 +51,8 @@ Guidance:
 - for `provider="openai_compat"`, loopback endpoints such as
   `http://localhost:11434/v1` receive an automatic placeholder token when no
   key is configured
+- `provider="ollama"` is a notebook-facing convenience alias over the same
+  OpenAI-compatible backend and automatically uses that loopback base URL
 - non-loopback OpenAI-compatible endpoints still require a real key through
   `api_key=...`, `OPENAI_COMPAT_API_KEY`, `OPENAI_API_KEY`, or `.env.local`