@mediadatafusion/pi-workflow-suite 0.0.9 → 0.0.11

package/CHANGELOG.md

@@ -2,6 +2,44 @@
 
 All notable public releases will be documented in this file.
 
+## [0.0.11] - 2026-05-30
+
+### Added
+
+- `workflow_browser_check` tool — headless browser verification for validator mode with interactive actions (click, type, read, reload, screenshot, evaluate). Uses Puppeteer from the Pi runtime so validators can verify web app behavior regardless of the target project's dependencies.
+- Token budget controls (`maxTokens`, `maxRuntimeHours`) for Plan, Mission, and Standard modes.
+- Structured validation boolean fields (`concreteRepairableIssue`, `manualVerificationRequired`, `evidenceGap`) on workflow and mission state for infallible classification.
+- `/plan complete` command for explicit Plan Mode completion.
+- Mission reviewer and workflow reviewer prompt templates.
+
+### Hardened
+
+- **Validation pipeline**: PARTIAL PASS with no concrete code defects now completes the workflow. Classifier reordered so concrete fixes route to repair over evidence gaps. Expanded automatable-evidence-gap detection. Mission validation manual-only outcomes advance milestones; final-validation manual-only outcomes complete the mission.
+- **Reviewer and repair**: Mission reviewer auto-repair uses centralized default-enabled configuration matching Plan Mode. Built-in mission defaults aligned (reviewer auto-repair enabled, retry mode `safe_only`, max retries 2). Consistent retry gating across both modes.
+- **Tool guard and Repo Lock**: Safe-command recognition expanded across package managers and ecosystems (pnpm, yarn, bun, npx serve, python3, curl localhost, ps, pgrep, sleep). Shell preamble handling (`stripSafePreamble`) for `set -e` and `export` patterns. `/tmp/` and `/dev/` paths exempted from Repo Lock blocking. Reduced false-positive destructive-command blocks.
+- **Prompts and agents**: Unified inline-diagram guidance across all prompts, agents, and skills. Web app verification procedures with structured evidence output requirements in validator prompts. Sub-agent write-ownership clarified in mission run prompt. Agent Mermaid guidance updated for raw blocks since sub-agents lack `workflow_diagram`.
+- **Runtime accounting**: Wall-clock age uses terminal timestamp when workflow is stopped. Active-runtime tracking preserved for workflows that began before the current session.
+- **Plan Mode progress tracking**: Plan execution step progress now reliably tracks across all steps. The `workflow_progress` tool is guaranteed on the agent's active tool surface every turn. The progress guard enforces step activation before file writes while allowing sub-agents to run freely for research and preparation. Multi-step prompt guidance with inline step status display keeps the agent aligned with the approved plan from first step through final validation.
+
+### Fixed
+
+- Plan execution sub-agents no longer deadlock against the step progress guard when forced sub-agent policies are active.
+- Plan Mode step progress widget consistently updates across multi-step execution instead of staying stuck on step 1.
+
+### Updated
+
+- Validators can write temporary evidence-gathering scripts (was read-only).
+- Mission `maxRuntimeHours` default 8→13.
+- All 4 built-in presets updated with `planShowProgressBar`.
+- Internal architecture documentation expanded with model routing, settings merge chain, and preset bundle architecture.
+
+## [0.0.10] - 2026-05-25
+
+### Changed
+
+- Improved workflow reliability across Standard, Plan, and Mission execution, including stronger progress tracking and validation handoff behavior.
+- Tightened repository safety checks to keep guarded workflows scoped to the active project.
+
 ## [0.0.9] - 2026-05-23
 
 ### Changed

package/CONTRIBUTING.md

@@ -1,9 +1,19 @@
 # Contributing
 
-Pi Workflow Suite is a maintainer-led project. It is not currently operated as an open contribution project.
+Pi Workflow Suite is a maintainer-led project. Contributions are welcome only at maintainer discretion, and unsolicited pull requests may be closed without review.
 
-Feedback is welcome, but it is not a request queue. Issues, discussions, messages, or suggestions do not create an obligation for the maintainer to respond, investigate, prioritize, or implement a change.
+Before opening a pull request, discuss changes that affect workflow behavior, release safety, or maintenance burden.
 
-Unsolicited pull requests are not guaranteed to be reviewed and may be closed without action. Please do not open pull requests for features, behavior changes, dependency changes, packaging, workflow logic, or security-sensitive areas unless the maintainer has explicitly invited the change or discussed it with you first.
+Pull requests require explicit maintainer approval before changing:
 
-The maintainer may accept, defer, ignore, or decline suggestions based on project direction, complexity, risk, support burden, and available time.
+- workflow modes or mode state
+- Mission Mode behavior, milestones, validation, repair, or reviewer logic
+- Plan Mode approval, execution, validation, or repair flow
+- Standard Mode task handling, clarification, or To Do behavior
+- package publishing, GitHub Actions, or install scripts
+- security-sensitive logic
+- dependency behavior or dependency lists
+
+Contributors must not introduce telemetry, postinstall scripts, credential handling, network calls, obfuscated code, or new dependencies without explicit justification and maintainer approval.
+
+External contributions must preserve existing behavior unless a behavior change is explicitly approved. Feature requests may be declined if they increase scope, complexity, or support burden.

package/README.md

@@ -4,7 +4,7 @@
 
 [![Install](https://cdn.jsdelivr.net/npm/@mediadatafusion/pi-workflow-suite@0.0.6/docs/assets/readme-link-install.svg)](#installation) [![Quick Start](https://cdn.jsdelivr.net/npm/@mediadatafusion/pi-workflow-suite@0.0.6/docs/assets/readme-link-quick-start.svg)](#quick-start) [![Commands](https://cdn.jsdelivr.net/npm/@mediadatafusion/pi-workflow-suite@0.0.6/docs/assets/readme-link-commands.svg)](#core-commands) [![Settings](https://cdn.jsdelivr.net/npm/@mediadatafusion/pi-workflow-suite@0.0.6/docs/assets/readme-link-settings.svg)](#settings-reference)
 
-**Workflow Suite Version:** `v0.0.9`
+**Workflow Suite Version:** `v0.0.11`
 
 ## Overview
 
@@ -55,6 +55,7 @@ See Pi Workflow Suite in action: structured workflow modes, settings, runtime st
 - [Compaction Support](#compaction-support)
 - [Diagram Support](#diagram-support)
 - [Web Access](#web-access)
+- [Browser Verification](#browser-verification)
 - [Repository Lock](#repository-lock)
 - [Plan History](#plan-history)
 - [Mission Progress, Checkpoints, And Runtime Tracking](#mission-progress-checkpoints-and-runtime-tracking)
@@ -115,9 +116,10 @@ Pi Workflow Suite turns Pi into a guided workflow environment:
 | Mission Mode | Long-running milestone workflows with approval, checkpoints, Mission-specific model overrides, validation gates, repair/retry, pause/resume, final-validation controls, and continuity tracking. |
 | Themes And Startup UI | Workflow Suite themes, startup visual cards, startup logo modes, custom terminal logo text, custom brand cards, footer/status styling, widgets, and optional input border styling. |
 | Interactive Diagrams | `workflow_diagram` Mermaid support with terminal preview, SVG-first clickable artifacts, PNG/runtime rendering support, dark-mode-friendly styling, and runtime artifact storage. |
-| Web Research | First-party `workflow_web_search` and `workflow_web_fetch` tools for public web search/fetch with source URLs, blocked local/private/internal hosts, time/size limits, and untrusted-content handling. |
-| Repo Lock | Project-scoped Global Safety control that constrains path tools and conservative bash path detection to the current repo and Pi runtime, with clear non-sandbox caveats. |
+| Web Research & Browser Verification | First-party `workflow_web_search`, `workflow_web_fetch`, and `workflow_browser_check` tools. Search and fetch for public web evidence with source URLs, blocked local/private/internal hosts, and time/size limits. Headless browser verification for runtime web app validation with interactive UI actions (click, type, read, screenshot, evaluate). |
+| Repo Lock | Project-scoped Global Safety control that constrains normal file tools, bash path checks, and sub-agents to the active repository, with protected configuration paths and clear non-sandbox caveats. |
 | Compaction | Pi default, custom model, or disabled Workflow Suite compaction so context summarization can use its own provider/model, proactive threshold checks, idle-boundary execution, custom token tuning, adaptive fitting, status reporting, and safe fallback. |
+| Token Budgets | Optional per-mode token and runtime caps (`maxTokens`, `maxRuntimeHours`) for Plan, Mission, and Standard Mode. Off by default (unlimited). When enabled, Workflow Suite tracks cumulative usage and blocks further agent turns when the budget is exceeded. |
 | Workflow Roles | Planner, Executor, Reviewer, Validator, Mission, and compaction responsibilities are separated by phase so each job has clear boundaries and can be matched to the right model. |
 | Model Selection | Configure which provider/model and thinking level powers each workflow role, with shared defaults plus Standard-specific and Mission-specific overrides for simpler or higher-rigor setups. |
 | Presets | Built-in and custom workflow profiles with selector commands and Ctrl+Shift+U cycling while active modes are running. |
@@ -134,13 +136,15 @@ Pi Workflow Suite turns Pi into a guided workflow environment:
 - Mission Mode through `/mission`, `/m`, and `Ctrl+Shift+M` for durable milestone workflows.
 - Configurable clarification in Standard Mode, plus dynamic clarification in Plan Mode and Mission Mode.
 - Review, execution, validation, repair, retry, checkpoint, and final-validation controls where the selected mode supports them.
-- Plan history, mission checkpoint history, Standard runtime tracking, Mission runtime tracking, and mode-aware progress widgets.
+- Plan history, mission checkpoint history, Standard runtime tracking, and Mission runtime tracking.
+- Mode-aware progress widgets: Plan step tracking with step-by-step progress and validation gates, Mission milestone tracking with checkpoint history, and Standard Mode dynamic To Do progress.
 - Workflow settings UI for Standard Mode, Plan Mode, Mission Mode, model selection, sub-agents, compaction, widgets, themes, startup visuals, and safety.
 - Workflow themes with a `none` option, startup visual cards, startup logo modes, custom terminal logo text, custom brand cards, and optional themed input borders.
-- Integrated `workflow_web_search` and `workflow_web_fetch` tools for current public evidence and source-backed URL reading.
+- Integrated `workflow_web_search`, `workflow_web_fetch`, and `workflow_browser_check` tools for current public evidence, source-backed URL reading, and headless browser verification of web app runtime behavior.
 - Interactive `workflow_diagram` Mermaid rendering with terminal preview, clickable SVG artifacts, and PNG/runtime rendering support.
-- Repo Lock for project-scoped path safety around repository and Pi-runtime access.
+- Repo Lock for project-scoped path safety around repository work, protected project configuration, and sub-agent inheritance.
 - Role-aware model selection so planning, execution, review, validation, Mission work, and compaction can each use the provider/model and thinking level that fits the job.
+- Optional per-mode token and runtime budgets (`maxTokens`, `maxRuntimeHours`) to cap usage in Plan, Mission, and Standard Mode. Off by default; enable when you need predictable cost or time limits.
 - Sub-agent usage policies for planning, execution, repair, review, and validation, with explicit documentation that these are orchestration settings, not a universal permission manager.
 - Safe install, backup, audit, quarantine, verification, and package validation scripts.
 
@@ -215,7 +219,7 @@ Core behavior:
 - `/standard todo clear` clears the Standard To Do list.
 - `/standard exit` returns to idle.
 
-Standard Mode settings live under `standard.*`, including `autoTodoEnabled`, `todoTriggerMode`, `todoProgressVisible`, `clarificationEnabled`, `clarificationMode`, `maxClarificationQuestions`, `interactiveClarificationEnabled`, `clarificationTiming`, `clarificationQualityGate`, `allowClarificationWithoutAnalysis`, `useSubagentsBeforeClarification`, `allowSubagents`, `subagentScope`, Standard-specific sub-agent phase overrides, `statusWidgetVisible`, `modelRole`, and `useSharedExecutorModel`. These controls are user-configurable through `/workflow settings Standard Mode` or `/workflow-settings configure standard-mode`, and custom workflow presets can save/apply Standard Mode settings.
+Standard Mode settings live under `standard.*`, including `autoTodoEnabled`, `todoTriggerMode`, `todoProgressVisible`, `clarificationEnabled`, `clarificationMode`, `maxClarificationQuestions`, `interactiveClarificationEnabled`, `clarificationTiming`, `clarificationQualityGate`, `allowClarificationWithoutAnalysis`, `useSubagentsBeforeClarification`, `allowSubagents`, `subagentScope`, Standard-specific sub-agent phase overrides, `statusWidgetVisible`, `modelRole`, and `useSharedExecutorModel`. These controls are user-configurable through `/workflow settings Standard Mode`, and custom workflow presets can save/apply Standard Mode settings.
 
 ## Plan Mode
 
@@ -402,7 +406,7 @@ Standard Mode, Plan Mode, and Mission Mode use model settings differently:
 - **Plan Mode** supports formal planned execution: plan, approve, optionally review with a second model, execute with the selected executor model, optionally validate with an independent validator model, and optionally repair/retry failed validation.
 - **Mission Mode** supports persistent milestone work: plan mission milestones, approve the mission, execute the current milestone, validate that milestone, checkpoint, repair/retry if needed, optionally run final whole-mission validation, then continue or complete according to autonomy settings. Mission-specific role overrides let long-running work use different planner/executor/reviewer/validator choices from normal Plan Mode.
 
-The included example settings provide defaults, but users can change provider/model, thinking level, role enablement, reviewer/validator behavior, Mission Mode autonomy, and mission-specific model selection through `/workflow-settings`. Do not treat the shipped defaults as the only supported setup. Provider names must match the user's configured Pi/Factory model route and API compatibility; official providers and proxy/generic providers may require different provider values even when the display model name looks similar.
+The included example settings provide defaults, but users can change provider/model, thinking level, role enablement, reviewer/validator behavior, Mission Mode autonomy, and mission-specific model selection through `/workflow settings`. Do not treat the shipped defaults as the only supported setup. Provider names must match the user's configured Pi/Factory model route and API compatibility; official providers and proxy/generic providers may require different provider values even when the display model name looks similar.
 
 Thinking levels:
 
@@ -427,30 +431,85 @@ Configuration examples:
 /workflow settings Standard Mode
 /workflow settings Mission Mode
 /workflow settings Shared Compaction
-/workflow-settings configure models
-/workflow-settings configure standard-mode
-/workflow-settings configure mission-mode
-/workflow-settings configure compaction
-
-# Standard-specific model overrides
-/workflow-settings set standard useStandardSpecificModels true|false
-/workflow-settings set standard-models executor <provider> <model>
-/workflow-settings set standard-models validator <provider> <model>
-
-# Mission-specific model overrides
-/workflow-settings set missions useMissionSpecificModels true|false
-# Then use /workflow-settings configure mission-mode to select Mission Planner, Executor, Reviewer, and Validator models.
-
-# Compaction model selection and token budget
-/workflow-settings set context compactionMode custom_model
-/workflow-settings set context compactionModelProvider <provider>
-/workflow-settings set context compactionModel <model>
-/workflow-settings set context customCompactionEnabled true
-/workflow-settings set context customCompactionReserveTokens 4096-65536|default|reset
-/workflow-settings set context customCompactionKeepRecentTokens 1000-200000|default|reset
 ```
 
-Shared model selection is available through `/workflow settings Shared Models` or direct `/workflow-settings configure models` commands. Standard-specific and mission-specific model selection is available through their mode settings menus.
+The grouped settings menus expose shared role selection, Standard-specific model behavior, Mission-specific model behavior, and compaction model/token-budget controls without relying on legacy dashed command entry points.
+
+Shared model selection is available through `/workflow settings Shared Models`. Standard-specific and mission-specific model selection is available through their mode settings menus.
+
+## Efficiency Guidance
+
+Workflow Suite gives you independent control over workflow rigor and model cost. This section explains which settings affect token usage and how to tune them.
+
+### Thinking Levels
+
+Six thinking levels control how much reasoning the model applies per inference:
+
+```text
+off < minimal < low < medium < high < xhigh
+```
+
+Higher levels use more tokens. Recommendations by role:
+
+| Role | Guidance |
+|------|----------|
+| Planner | Higher thinking is often worth the cost — the plan defines scope, assumptions, risk, and validation strategy. |
+| Reviewer | Higher thinking helps catch missing requirements, unsafe steps, or weak plans before execution begins. |
+| Validator | Higher thinking reduces shared blind spots with the executor. An independent validator with a different model is more valuable than maxing thinking on the same model. |
+| Executor | Medium-high is usually sufficient. Execution is about precise tool use and instruction following, not open-ended analysis. |
+| Compaction | Summarization is mechanical. If using a custom compaction model, a lower thinking level or a cheaper model is often appropriate. |
+
+Note: Pi may clamp thinking levels for model/provider combinations that do not support the requested level. This is Pi runtime behavior, not a Workflow Suite setting.
+
+### Token Budgets
+
+Each mode supports an optional configurable token budget:
+
+- `planning.maxTokens` — caps estimated token usage for a Plan Mode workflow.
+- `missions.maxTokens` — caps estimated token usage for a Mission Mode workflow.
+- `standard.maxTokens` — caps estimated token usage for a Standard Mode session.
+
+Default is `0` (unlimited). When set to a positive value, Workflow Suite tracks cumulative usage and blocks further agent turns when the budget is exceeded. Set budgets with headroom — the tracker uses context window size as a proxy since Pi does not expose cumulative token counts.
+
+Configure through `/workflow settings Plan Mode`, `/workflow settings Mission Mode`, or `/workflow settings Standard Mode`.
+
+### Sub-Agent Policy And Token Cost
+
+Sub-agent policies control how many parallel workers are requested per phase:
+
+```text
+off < auto < deep < maximum < forced
+```
+
+Each worker has its own context window, so more workers multiply token spend. The built-in presets scale worker counts from 1 (simple) to 4 (maximum). For cost-sensitive work:
+
+- Use `auto` to let the model decide when workers are worth the cost.
+- Lower worker counts in `deep`/`maximum`/`forced` policies.
+- Disable phases that are not needed for the current task.
+
+Sub-agent settings are configured through `/workflow settings Shared Sub-agents`, with per-mode overrides in Standard Mode and Mission Mode settings.
+
+### Settings That Affect Token Usage
+
+| Setting | Impact |
+|---------|--------|
+| Thinking levels (per role) | Directly controls tokens per inference for each workflow phase. |
+| Sub-agent policies and worker counts | More workers = more parallel context windows = higher total spend. |
+| `maxClarificationQuestions` | Higher counts mean more clarification turns before work begins. |
+| `planning.depth` | `deep`/`maximum` prompt for more sub-agent research before planning. |
+| `validationRetryMode` | `aggressive_within_scope` can trigger more repair cycles. |
+| `finalValidationEnabled` | Adds a whole-mission validation pass after all milestones complete. |
+| `maxTokens` (per mode) | Optional budget cap; blocks further turns when exceeded. |
+
+### Presets And Models Are Independent
+
+Presets control workflow behavior (approval gates, review/validation automation, sub-agent policy, repair retries). Models control which provider/model powers each role. They are intentionally separate:
+
+- Cycling presets does not change model selections.
+- Changing models does not affect preset behavior.
+- You can run `deep` preset with small models or `simple` preset with large models.
+
+This separation lets you tune workflow rigor and model cost independently.
 
 ## Workflow Settings UI
 
@@ -476,16 +535,7 @@ Public slash menu entries use the grouped `/workflow settings ...` surface. Use
 /workflow settings Summary
 ```
 
-Direct legacy compatibility settings commands are also available for command-line style configuration:
-
-```text
-/workflow-settings
-/workflow-settings list
-/workflow-settings help
-/workflow-settings scope
-/workflow-settings write-target
-/workflow-settings create-project-override
-```
+Public command discovery is through `/workflow help` and the grouped `/workflow settings ...` entries above. Legacy dashed compatibility routes may exist for older scripts, but they are not public slash-menu commands and are not the recommended README surface.
 
 Settings menus:
 
@@ -538,7 +588,7 @@ Sub-agents: forced maximum teams across planning/execution/repair/review/validat
 Mission: supervised auto, final validation, higher retry budget
 ```
 
-`/workflow settings Show Current Settings` and `/workflow-settings list` print an Active Profile section near the top so the active preset is explained before the detailed settings.
+`/workflow settings Show Current Settings` prints an Active Profile section near the top so the active preset is explained before the detailed settings.
 
 Quick access:
 
@@ -588,24 +638,6 @@ Open the interactive theme menu from the public settings surface:
 /workflow settings Theme
 ```
 
-Direct theme commands are also available:
-
-```text
-/workflow-settings theme list
-/workflow-settings theme use aurora|synthwave|matrix|nebula|ember|arctic|oceanic|royal|solar|graphite|access|diagnostic|classic|MediaDataFusion|none
-/workflow-settings theme startup mission_control|diagnostic_center|workflow_duo|data_stream|neural_grid|minimal|custom_brand|none
-/workflow-settings theme startup-logo none|pi|custom
-/workflow-settings theme logo-text <letters>
-/workflow-settings theme logo-font block|shadow|outline|wide|double|three_d
-/workflow-settings theme logo-shadow down_right|down|up|left|right
-/workflow-settings theme logo-color theme|primary|split
-/workflow-settings theme startup-on-open enable|disable
-/workflow-settings theme preview
-/workflow-settings theme brand enable|disable
-/workflow-settings theme brand text <custom text>
-/workflow-settings theme brand base minimal|workflow_duo|mission_control|diagnostic_center|data_stream|neural_grid
-```
-
 The interactive menu is the easiest way to configure appearance:
 
 ```text
@@ -632,38 +664,14 @@ How the pieces fit together:
 
 `startupVisual: none` is separate. It disables only the startup visual card. It does not disable the selected Workflow Suite theme, Standard Mode, Plan Mode, Mission Mode, widgets, presets, or commands.
 
-Practical recipes:
+Practical recipes use the guided appearance menu:
 
 ```text
-# Open the guided appearance menu
 /workflow settings Theme
-
-# Preview the current startup card and logo
-/workflow-settings theme preview
-
-# Choose a complete visual style
-/workflow-settings theme use synthwave
-/workflow-settings theme startup mission_control
-/workflow-settings theme startup-logo pi
-
-# Add your own short terminal logo above the card
-/workflow-settings theme startup-logo custom
-/workflow-settings theme logo-text ACME
-/workflow-settings theme logo-font shadow
-/workflow-settings theme logo-color primary
-
-# Use a branded startup card without changing workflow behavior
-/workflow-settings theme startup custom_brand
-/workflow-settings theme brand text Acme Workflow
-/workflow-settings theme brand base mission_control
-
-# Turn off only the startup card
-/workflow-settings theme startup none
-
-# Turn off Workflow Suite visual theming while keeping features active
-/workflow-settings theme use none
 ```
 
+From that menu users can preview the current startup card and logo, choose a complete visual style, configure a short terminal logo, configure a branded startup card, turn off only the startup card, or opt out of Workflow Suite visual theming while keeping workflow features active.
+
 ## Sub-Agents And Parallel Work
 
 Pi Workflow Suite includes reusable workflow agents and skills. Agents are isolated-context workers that can be invoked by the sub-agent tool or by Workflow Suite orchestration policy. Skills are bundled guidance modules for repeatable workflow practices. Runtime tools such as `workflow_web_search`, `workflow_web_fetch`, `workflow_diagram`, `workflow_progress`, and `standard_todo` are separate from both agents and skills.
@@ -696,6 +704,16 @@ They include:
 - global and project agent discovery,
 - parallelism preferences for workflow phases.
 
+Sub-agent orchestration varies by mode and phase:
+
+| Mode | Planning | Execution | Validation |
+|---|---|---|---|
+| Plan | Research, codebase inspection, risk discovery | Scoped implementation help, file inspection, patch planning | Evidence gathering, regression search |
+| Mission | Milestone planning research, dependency analysis | Per-milestone implementation support | Per-milestone and final validation evidence |
+| Standard | Task analysis, approach research | File inspection, implementation assistance | Quality review, regression checking |
+
+Forced sub-agent policies (available in all three modes) require a minimum number of successful workers before the agent can proceed to file writes, ensuring independent analysis and preparation are applied before implementation.
+
 Important limits:
 
 - Pi Workflow Suite does **not** provide a UI for editing arbitrary sub-agent tool permissions.
@@ -716,7 +734,7 @@ Commands:
 /workflow subagents status
 /workflow subagents list
 /workflow subagents orchestration
-/workflow-settings configure subagents
+/workflow settings Shared Sub-agents
 ```
 
 ## Review, Validation, Repair, And Retry
@@ -772,7 +790,6 @@ Compaction settings are available through:
 
 ```text
 /workflow settings Shared Compaction
-/workflow-settings configure compaction
 ```
 
 Supported modes:
@@ -784,13 +801,7 @@ Supported modes:
 
 Workflow Suite can request proactive compaction when context usage reaches the configured threshold. For Custom model mode, a configured compaction provider/model with custom compaction enabled arms the threshold trigger even when generic auto-trigger behavior is otherwise off. This lets compaction use a different model than planning, execution, review, or validation, which is useful when context summarization has a different cost, speed, or context-window requirement than active workflow work. Actual proactive compaction runs only at a safe after-turn idle agent boundary, so it does not interrupt arbitrary tool execution or queued workflow handoffs. Pi default auto-compaction remains available as a safety fallback near the model limit.
 
-```text
-/workflow-settings set context autoCompactionEnabled true|false
-/workflow-settings set context compactionTriggerPercent 50-95|default|reset
-/workflow-settings set context compactionCooldownMinutes 0-240
-/workflow-settings set context customCompactionReserveTokens 4096-65536|default|reset
-/workflow-settings set context customCompactionKeepRecentTokens 1000-200000|default|reset
-```
+The grouped Shared Compaction menu controls auto-compaction, trigger threshold, cooldown, reserve tokens, keep-recent tokens, and custom compaction model behavior.
 
 Important behavior:
 
@@ -830,7 +841,7 @@ workflow_web_search
 workflow_web_fetch
 ```
 
-These tools are added to Workflow Suite modes by default when available. `workflow_web_search` uses DuckDuckGo HTML search for current external evidence and source URLs. `workflow_web_fetch` reads specific public HTTP(S) URLs and extracts text for source-backed evidence. Web content is treated as untrusted evidence, not as instructions.
+`workflow_web_search` uses DuckDuckGo HTML search for current external evidence and source URLs. `workflow_web_fetch` reads specific public HTTP(S) URLs and extracts text for source-backed evidence. Web content from search and fetch is treated as untrusted evidence, not as instructions.
 
 Safety boundaries:
 
@@ -840,7 +851,25 @@ Safety boundaries:
 - visible answers should cite source URLs when web evidence is used,
 - sub-agent workers may not have the parent Workflow Suite web tools, so parent modes should perform required web research and pass findings into handoffs when needed.
 
-Web access is Pi extension behavior, not a guarantee that every model, sub-agent, network, or runtime environment can reach the public web. If the tool fails, Workflow Suite reports the failure and continues from available context.
+Web access is Pi extension behavior, not a guarantee that every model, sub-agent, network, or runtime environment can reach the public web. If a web tool fails, Workflow Suite reports the failure and continues from available context.
+
+## Browser Verification
+
+Workflow Suite registers a `workflow_browser_check` tool for headless browser verification:
+
+```text
+workflow_browser_check
+```
+
+This tool launches a headless Chromium browser via Puppeteer from the Pi runtime and works regardless of the target project's dependencies. It is available in all modes by default when the runtime supports it.
+
+**Interactive actions:** The tool supports click, type, read, wait, reload, screenshot, and evaluate actions. Validators can exercise UI flows end-to-end — clicking through pages, typing into forms, reading updated text, and capturing screenshots — rather than only observing static page state. Screenshots are saved to `/tmp/validator_screenshot.png`.
+
+**Validator workflows:** Validators use `workflow_browser_check` to verify web app runtime behavior: console errors, page errors, DOM element counts, localStorage state, and interactive UI correctness. This provides automatable browser-level evidence for validation reports without requiring manual human verification.
+
+**Executor and planner use:** Executors and planners can also use the tool to verify their own work during implementation — starting a dev server, running browser checks, and confirming behavior before handing off to validation.
+
+**Graceful fallback:** If Puppeteer is not available in the Pi runtime, the tool reports the error and the workflow continues from available context. Browser verification is an enhancement, not a hard dependency.
 
 ## Repository Lock
 
@@ -850,12 +879,16 @@ Repo Lock is a Global Safety setting controlled through:
 /workflow settings Global Safety
 ```
 
-The underlying setting is `safety.repoLockEnabled`. The interactive toggle is project-scoped: it writes to the active repository override at `.pi/workflow-settings.json` so Repo Lock can be enabled for one project without changing every Pi session. When enabled, Workflow Suite scopes path-based tools such as read, grep, find, ls, edit, and write to the current Git repository root and the live Pi runtime. Bash path detection is conservative and blocks detected paths outside the current repository or Pi runtime.
+The underlying setting is `safety.repoLockEnabled`. The interactive toggle is project-scoped: it writes to the active repository override at `.pi/workflow-settings.json` so Repo Lock can be enabled for one project without changing every Pi session.
+
+When enabled, Repo Lock keeps normal file tools, conservative bash path checks, and Workflow Suite sub-agents inside the active repository. Project `.pi` files may be read for settings and instruction context, but protected project control paths such as `.pi/workflow-settings.json`, `.pi/settings.json`, and `.pi/agents/**` are not edited through normal file tools. Use the dedicated settings UI/commands for intentional Workflow Suite settings changes, or temporarily disable Repo Lock, make the configuration change, and re-enable it.
 
-Repo Lock allows access to the Pi runtime directory for installed Workflow Suite tools, agents, skills, prompts, and runtime resources. Sub-agent calls are checked at the parent current working directory, but sub-agent child processes are guided by their own agent configuration and tool allow-list.
+Repo Lock does not grant normal agent tools access to the live Pi runtime under `~/.pi/agent`. Workflow Suite internals still use the runtime for required state, settings, widgets, agents, skills, prompts, and install resources, but target-repository workflows should not inspect or mutate live runtime files through generic read/edit/write tools.
 
 Repo Lock helps prevent accidental cross-repository work. It is not an operating-system sandbox, a complete shell parser, or a guarantee that every possible child process is contained. Review commands before running them, especially commands that invoke other tools or scripts.
 
+Repo Lock is enabled by default in the Standard, Deep, and Maximum built-in presets. If your workflow requires cross-repository access, disable it through `/workflow settings Global Safety` or by setting `safety.repoLockEnabled` to `false`.
+
 ## Plan History
 
 Plan history can persist workflow plans under Pi runtime state. Saved plans include:
@@ -927,16 +960,7 @@ Widget commands:
 /workflow widgets off
 ```
 
-Footer hints can be tuned without disabling the actual commands/shortcuts:
-
-```text
-/workflow-settings set ui showIdleWorkflowEntryHint true|false
-/workflow-settings set ui showActiveWorkflowSwitchHint true|false
-/workflow-settings set ui showWidgetShortcutHint true|false
-/workflow-settings set ui showPresetShortcutHint true|false
-```
-
-The interactive path is `/workflow settings UI Widgets` → `Footer Hints`. Direct command users can also open it with `/workflow-settings configure widgets`.
+Footer hints can be tuned without disabling the actual commands/shortcuts. The interactive path is `/workflow settings UI Widgets` → `Footer Hints`.
 
 Mission heartbeat and stale-status fields are tracked and displayed. Checkpoint interval settings record the preferred cadence for future timed checkpoint automation, while recovery actions remain user-supervised for safety.
 
@@ -971,6 +995,15 @@ cd /path/to/project
 pi install -l npm:@mediadatafusion/pi-workflow-suite
 ```
 
+### Installing specific versions
+
+```bash
+pi install npm:@mediadatafusion/pi-workflow-suite@0.0.11
+pi install -l npm:@mediadatafusion/pi-workflow-suite@0.0.11
+```
+
+An unversioned install follows normal update behavior: `pi update` and `pi update --extensions` will pick up new package releases. A versioned install pins the package to that version. Pinned package specs are intentionally skipped by Pi's normal package update commands. To move a pinned install to a newer version, reinstall with the desired version. To switch back to latest tracking, use the unversioned install command without `@<version>`.
+
 ### Source install
 
 ```bash
@@ -1001,6 +1034,7 @@ Operational scripts:
 | `scripts/backup-live.sh` | Create a timestamped live-runtime backup while excluding credentials, sessions, logs, and workflow state. |
 | `scripts/quarantine-live-junk.sh` | Dry-run or move known stale runtime debris to quarantine; it does not delete files. |
 | `scripts/bootstrap-project.sh /path/to/project` | Create project-local Workflow Suite setup files for a target project. |
+| `scripts/sync-from-live.sh` | Maintainer synchronization helper for reviewing live runtime resources before deciding what belongs in source. |
 
 The live Pi runtime should not contain a top-level `.git`, stale `*.backup.*` / `*.broken.*` files in active resource directories, or old recovery/disabled directories mixed with current resources. Quarantine moves files; it does not delete them.
 
@@ -1115,7 +1149,7 @@ Example defaults shipped with the suite include Standard Mode enabled with confi
 
 Users can change the workflow shape. For example, a user may disable reviewer involvement for fast local work, use a stronger reviewer for corporate policy review, route executor to a tool-use/code-writing model, route validator to a separate high-reasoning model, or use mission-specific models for long-running work.
 
-Use `/workflow settings Show Current Settings` or `/workflow-settings list` for the effective merged Workflow Suite configuration, and `/workflow-settings scope` to see the Workflow Suite write target. For Pi core settings versus Workflow Suite settings, run `./scripts/audit-settings.sh [target-cwd]`; it reports global/project paths and safe summaries without writing settings or printing secrets.
+Use `/workflow settings Show Current Settings` for the effective merged Workflow Suite configuration. For Pi core settings versus Workflow Suite settings, run `./scripts/audit-settings.sh [target-cwd]`; it reports global/project paths, Workflow Suite write targets, and safe summaries without writing settings or printing secrets.
 
 Workflow Suite settings are currently global/project scoped, not session-local. A global preset/theme/model change can affect every session using global settings; a project `.pi/workflow-settings.json` can affect sessions launched under that project. Use project overrides for per-project behavior today. A true session-local profile lock should be treated as a separate future runtime feature; see `docs/SESSION_PROFILES.md` for the design.
 
@@ -1152,7 +1186,7 @@ Common recovery commands:
 ```text
 /workflow status
 /workflow settings Show Current Settings
-/workflow-settings scope
+./scripts/audit-settings.sh [target-cwd]
 /mission status
 /mission resume
 /workflow widgets list
@@ -1171,10 +1205,10 @@ See `docs/TROUBLESHOOTING.md` for detailed diagnostics.
 
 ## Versioning
 
-The current public preview version is `v0.0.9`. Version information is intentionally aligned across:
+The current preparation version is `v0.0.11`. Version information is intentionally aligned across:
 
-- `VERSION` (`v0.0.9`),
-- `package.json` (`0.0.9`),
+- `VERSION` (`v0.0.11`),
+- `package.json` (`0.0.11`),
 - `package-lock.json`,
 - this README,
 - Workflow Suite settings/about output.
@@ -1189,13 +1223,11 @@ Apache-2.0 licenses the code, not the MediaDataFusion names, Workflow Suite name
 
 This project is not officially affiliated with, endorsed by, sponsored by, or maintained by Pi or any third-party platform unless explicitly stated in official project materials.
 
-Security issues should not be reported through public issues, public pull requests, or public discussions. See `SECURITY.md`.
+Security issues should be reported privately, not through public issues. See `SECURITY.md`. A private reporting channel will be published before broad public release.
 
-Pi Workflow Suite is maintainer-led and provided as-is. Feedback may be considered, but issues are not support tickets and no response or implementation timeline is promised. See `SUPPORT.md`.
+Support is maintainer-led and best-effort. See `SUPPORT.md`.
 
-Pull requests are not an open contribution channel. Discuss changes first or wait for an explicit maintainer invitation. See `CONTRIBUTING.md`.
-
-Paid consulting through MediaDataFusion may be available separately for implementation, integration, or workflow design work.
+Contributions are welcome when they align with the project direction. Workflow behavior, installation, dependency, security, and release changes require maintainer review. See `CONTRIBUTING.md`.
 
 ## Release Status
 
@@ -1206,20 +1238,12 @@ The intended package and repository identities are:
 https://github.com/MediaDataFusion/pi-workflow-suite
 ```
 
-The current release candidate is prepared as `@mediadatafusion/pi-workflow-suite@0.0.9`.
-
 Private DEV, private main, and the clean public release repository should carry the same approved package version before publication.
 
-After npm publication, install with:
-
-```bash
-pi install npm:@mediadatafusion/pi-workflow-suite@0.0.9
-```
-
-After npm publication, temporary evaluation in a current Pi run can use:
+Published public package versions are installed from npm with:
 
 ```bash
-pi -e npm:@mediadatafusion/pi-workflow-suite@0.0.9
+pi install npm:@mediadatafusion/pi-workflow-suite@<version>
 ```
 
 ## Planned Enhancements

package/SECURITY.md

@@ -2,6 +2,10 @@
 
 Do not report security issues in public issues, public pull requests, or public discussions.
 
-A public vulnerability intake process has not been opened yet. Until one is published, broad public vulnerability intake is not available.
+Private security reporting contact is not yet configured. This is a release blocker before enabling broad public issue intake or accepting outside security reports.
 
-Do not submit pull requests that add telemetry, credential handling, postinstall scripts, obfuscated code, unexplained network calls, or new dependencies without prior maintainer approval.
+Supported versions will be listed after the first public release. Until then, only the current private preparation version is under active review.
+
+Malicious pull requests, suspicious dependency changes, postinstall scripts, credential collection, telemetry, obfuscated code, or unexplained network behavior will be rejected.
+
+When reporting a vulnerability privately after a reporting channel is configured, include the affected version, install method, reproduction steps, impact, and any relevant logs with secrets removed.

package/SUPPORT.md

@@ -1,9 +1,7 @@
 # Support
 
-Pi Workflow Suite is a free, maintainer-led project provided as-is, without a support SLA.
+Pi Workflow Suite is provided without a support SLA. Free use does not imply free support.
 
-GitHub issues and discussions, if enabled, are for feedback and public signal only. They are not support tickets, and submitting an issue does not create an obligation for the maintainer to respond, investigate, prioritize, or implement a change.
+Support is provided at maintainer discretion. Before requesting help, read the README, release notes, and relevant troubleshooting guidance, and include the package version, install method, operating system, Pi version if known, commands run, and exact error output.
 
-Bug reports and thoughtful feedback are welcome, but response time and roadmap fit are entirely at maintainer discretion.
-
-Priority help, implementation support, integration work, or workflow design may be available separately through a paid MediaDataFusion engagement.
+Paid consulting through MediaDataFusion may be available separately for implementation, integration, or workflow design work.

package/VERSION

@@ -1 +1 @@
-v0.0.9
+v0.0.11

package/config/prompts/mission-final-validation.md

@@ -14,8 +14,9 @@ Rules:
 - Validate the original mission goal across all milestones, not only the last milestone.
 - Review milestone outcomes, checkpoints, validation reports, repair history, changed files, tests/builds, integration risks, and unresolved issues.
 - Return PASS only when the complete mission goal is satisfied and no blocking risk remains.
-- Return PARTIAL PASS when the mission appears complete but manual/visual/browser verification remains or evidence is incomplete without a concrete code defect.
+- Return FAIL when concrete missing requirements, regressions, unsafe changes, repairable defects, or concrete code/content/citation/source/file/metadata/artifact fixes remain.
+- Return PARTIAL PASS only when manual/visual/browser verification remains or evidence is incomplete without a concrete repairable issue.
 - Evidence gaps are not repairable defects unless a concrete missing requirement or artifact is identified.
-- Return FAIL only for concrete missing requirements, regressions, unsafe changes, or other repairable defects.
+- If concrete repairable issues remain, mark Concrete Repairable Issue: yes, list them clearly, and prefer FAIL over PARTIAL PASS.
 
 Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style. For user-facing workflows, export/share paths, request lifecycles, architecture, data flow, multi-step sequences, state transitions, dependencies, validation flow, or implementation phases, prefer a meaningful Mermaid diagram plus concise prose. Use concise labels and the right diagram type; do not hardcode random style/classDef/light-theme overrides unless the user explicitly asks. Skip diagrams for trivial responses.