(DONT-REVIEW-YET) feat(self-driving): Add the self-driving program to set up PostHog Self-driving#642
(DONT-REVIEW-YET) feat(self-driving): Add the self-driving program to set up PostHog Self-driving#642sortafreel wants to merge 42 commits into
self-driving program to set up PostHog Self-driving#642Conversation
🧙 Wizard CIRun the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands: Test all apps:
Test all apps in a directory:
Test an individual app:
Show more apps
Results will be posted here when complete. |
This stack of pull requests is managed by Graphite. Learn more about stacking. |
…ons is reachable evaluateAskCap rejected every call once askCallCount reached ASK_BATCH_THRESHOLD (3), and the rejected call never advanced the counter — so the nudge repeated forever and any maxQuestions above 3 was unreachable. Track the nudge in the server closure and pass it to evaluateAskCap so the batch-your-questions error fires exactly once, after which sequential asks proceed up to the real cap. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
New skill-based program that sets up PostHog Product Autonomy
(Signals) for an already-onboarded project. The agent runs the
context-mill product-autonomy-setup skill to enable the right signal
sources, require the GitHub integration, confirm org AI-data-processing
approval, and materialize + tune the scout fleet, then writes
posthog-product-autonomy-report.md.
- detect step requires posthog-setup-report.md; custom intro screen
renders the typed detect errors
- scope additions: task:read/write (signal source configs live under
the task scope object), integration:read, signal_scout:read/write
- requestDeepLink learns optional {purpose, path} so postRun can mint
an inbox deep link for the outro
- no keep-skills step: the transient setup skill is removed in postRun
- .gitignore re-includes src/lib/ so user-global lib/ ignore patterns
cannot silently drop program sources from commits
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
sortafreel
force-pushed
the
wizard/add-logs-fix-local-rins
branch
from
9fcc815 to
6f1c211
Compare
sortafreel
force-pushed
the
feat/product-autonomy
branch
from
2d86ad7 to
af15908
Compare
sortafreel
changed the base branch from
wizard/add-logs-fix-local-rins
to
graphite-base/642
sortafreel
force-pushed
the
graphite-base/642
branch
from
6f1c211 to
96e4621
Compare
|
hey @sortafreel!! just a heads up, once the CLI overhaul merges tomorrow AM you're gonna hit a resolution should be straightforward, just re-add your |
Validated review of this PR (self-review)I re-ran the AI review report against the actual code on this branch: each of the 22 findings was checked by a reviewer agent and then adversarially re-checked by a second agent (44 agents total). Kept = a real problem that could plausibly happen in production; dropped = wrong about the code or purely theoretical. The adversarial pass corrected 9 findings (notably walking three original Each kept finding is posted as an inline comment on the diff (reviewer voice) with a threaded reply in an agent-written author voice (labelled Agent response — these replies were drafted by the validation agents, not by me) — both under my account, so the reasoning is visible on the line. Result: 20 kept, 2 dropped. Kept
Dropped
3-5-2 — Clipboard subprocess has no timeout/kill, but cannot hang or zombie the CLI ❌ The mechanism is accurately described — no timeout, close-only resolve, and the effect ignores but doesn't kill the child — but the finding's headline harm is refuted by the code. It cannot "hang the CLI" or "keep the wizard process alive after the overlay exits": every termination path calls process.exit() (ExitScreen.tsx:12; start-tui.ts:92-95; wizard-abort.ts:93), and process.exit() tears down any lingering child immediately. start-tui.ts:88-91 documents exactly this defense against background handles producing a "zombie wizard." The call is also fire-and-forget ( 1-7-1 — Self-driving prompt does not claim AI approval is guaranteed; consent is gate-owned ❌ Agree this should be dropped. The quoted text ("approval is guaranteed... do not abort") does not exist in the prompt, and the cited lines are the GitHub step. Org AI consent is deliberately not the prompt's job: withAiOptInGate parks the runner before any source leaves the machine on the interactive path, using the strict is_ai_data_processing_approved===true reading (ai-opt-in-gate.ts), and ARCHITECTURE.md §6.3 spells out that neither prompt nor skill has an AI step anymore. The CI auto-consent the finding leans on (gate: session.ci || aiApproved; LoggingUI auto-resolves) is the documented intended behavior for the wizard's own Claude usage, and it cannot silently succeed: a CI self-driving run aborts at the first wizard_ask-needing step with [ABORT] requires-interactive-mode (a handled abort case), and --ci is disabled in published builds anyway. The only residual — that the backend Signals emit gate also fail-closes on org approval, independent of the wizard's gate — is a backend emit-gating concern, not a bug in this prompt, and isn't reachable today on this beta-flagged interactive flow. |
Problem
Changes
self-drivingcommand and program, gated behind its own program id. It requires the baseposthog-integrationflow to have run first.Shared Wizard changes — all optional, nothing else is affected
richLinksand long URLs render as terminal hyperlinks (with a clipboard fallback) instead of wrapping into garbage. Off by default, so other prompts are untouched.Test plan