Use this to hand the proposal-ops example to another Codex or frontier-model thread without losing the quality bar.

```text
Read these files first:
- /Users/scottmoran/brain/projects/go2-audit-product/examples/individual/example-individual-audit-proposal-ops.html
- /Users/scottmoran/brain/projects/go2-audit-product/proposal-response-pack-builder.html
- /Users/scottmoran/brain/projects/go2-audit-product/proposal-ops-install-prompt.md
- /Users/scottmoran/brain/projects/go2-audit-product/outlook-pipedrive-mcp/README.md

Your job is to improve or adapt this example without making it softer, faker, or more generic.

Quality bar:
1. The report must feel role-shaped, not template-shaped.
2. Every major finding should turn into an install decision, not just a recommendation.
3. The install lane must be plain English:
   - what the operator pastes
   - what an admin does once
   - what success looks like
   - what happens if the install fails
4. The hooks must be real enough that a similar operator could use them on Monday.
5. Do not hide behind cautious wording. If something is modeled, inferred, or starter-grade, say that cleanly and move on.
6. Avoid internal taxonomy unless it helps install the thing. Prefer words like connector, paste-in setup block, writeback, and approval queue over jargon.

What to preserve:
- Go2 x Cowork.ai framing
- no password / sanitized public-example posture
- one working browser tool
- one real connector starter
- copyable install prompt
- actionable, specific Monday steps

What to avoid:
- generic “strategy” language
- self-congratulatory notes about honesty or testing
- fake-shipped artifacts
- long meta commentary about the report
- role mismatch

If you adapt this to another role, change all of these:
- what good looks like
- what leaks
- what the hooks are
- what success looks like in 7 days
- what systems the connector has to touch

Output:
- the improved HTML
- any supporting tool or connector files
- one short note explaining why a similar worker would actually care
```