docs: propose request-to-product intake and decision flow (#1839)

BUILD-LOG.md

@@ -5973,3 +5973,7 @@ Owner directed static-only fallback after actual nativepriority drift: no new pr
 2026-11-03T04:07:40Z | Claude Opus 5.5 implementation sub-agent (lead T3 c5c1e8ba) | editor-browser.test.mjs:154 under Chromium 156 (Vikunja #784) on t3/editor-chromium-156, test commit 0c6aa1a1e on 1ff45c4ad | Case 2, no product defect: Chromium 156 checks script-src-attr when an inline handler attribute is created, also in a document with no window (WPT PR 62762; PR 64290 later skips such documents and 156 lacks it). All four reports come from prosemirror-view readHTML's innerHTML parse into a new createHTMLDocument (editor.js:8212:19, target the page document, one per pasted handler: img onerror, a onclick, a onmouseover, svg onload); no on* attribute reaches the live page and injected stays null; Chromium 153, 151 and Brave 154 report none for the same paste. Fix is test-only: the page's CSP record sets aside a script-src-attr report whose sourceFile is /editor.js, whose line is readHTML's parse (computed from the bundle, with a guard pinning those lines and detachedDoc) and whose target is the document; quiet(), inert(), injected, errors, rejections and the Console CSP are unchanged. New test: after a hostile paste, a handler set on a live editor paragraph, one parsed into a page-owned element never attached, and one set through prosemirror-view's attributes prop each still fail quiet(). editor-browser 17/17, editor plus editor-provenance 11/11, no skips; 4 mutants killed (all script-src-attr, target only, target only without the paragraph case, editor.js at any line). Residual: an element from that parse attached to the page after its report was sent would not be caught by the CSP record; on 156 its listener is never set. Full webui suite not run (bundle not rebuilt); Chromium 152 not on the host. No push, queue or PR action.
 2026-11-03T04:12:57Z | Claude Opus 5.5 implementation sub-agent (lead T3 c5c1e8ba) | Vikunja #415 and #416, .53 and .54 Console writes, on t3/console-writes-53-54, fix commit bd79daffd on 1ff45c4ad | Factory: scripts/case2-unit.sh takes the paired bare --sso --send (the lane b00019548 serve_flags rule), refuses either alone, still refuses the preview set and the proof pair, and before any unit write a bounded query run as the stack user, through the existing config-query supervisor, checks for console.sso. Library: unchanged and still read-only. Library --send with forward-auth and proof is not done: since #385 the tip's Console refuses --send without --sso (packages/webui/src/cli.mjs:63, serve.mjs:681), and reverting that is more than about 40 lines across the webui, service, release and upgrade scripts and reopens a reviewed security boundary, so it goes back to the lead. docs/guides/case1-business.mosaic-stack.json launches claude-opus-5-5 with provider proxy, route anthropic, under account factory with credential proxy. Tests: 5 new in case2-unit.test.mjs (4 RED on base) and 1 updated; case1-business-file.test.mjs 1 updated (RED on the base document) and 1 new. Runs: cli case2-unit 88/88, stack-upgrade 25/25, case1-accept 53/53; business case1-business-file 8/8, case1-project-key 3/3, chief-library-credentials 3/3; no skips. Mutants: factory --send without --sso and library without --proof-header required, each killed. Not done: scripts/case1-accept.sh still refuses --sso and --send in the args file (out of scope). No push, queue or PR action.
 2026-11-03T04:36:00Z | Claude Sonnet 5.5 implementation sub-agent (lead T3 c5c1e8ba) | editor-browser.test.mjs paste test, round 2 for Vikunja #784 on t3/784-r2, test commit e71222d1a on 0c6aa1a1e | GPT review of 0c6aa1a1e found that the CSP filter (directive, editor.js, readHTML line, target document) also sets aside a handler-bearing element that is attached to the live page and removed before its report is sent, because Chromium then targets the document too. The reviewer's insertion after editor.js:8212 (append reviewNode to body, put it back) passed the paste test and the live-handler test; reproduced here, editor-browser 17/17 with it. Fix is test-only: the page record now runs a MutationObserver on the live document (subtree, childList, attributes) that notes an added element, or a descendant of one, carrying an on* attribute and any on* attribute set in the page, without reading CSP events; h.quiet() asserts window.__live is empty; the live-handler test gains a case for a handler attached and removed in one turn and checks per case that the observer saw the handler (not for the page-owned element never attached). Runs: the reviewer's insertion now fails the paste test and the live-handler test with 'added a with onmouseover'; a variant that attaches a handler-bearing parent fails the same two; the four earlier weakened-filter mutants (all script-src-attr, target only, target only without the paragraph case, editor.js at any line) each fail the live-handler test, as does the observer pointed at a detached node; mutants in editor.js at another line and in app.js fail; one appended to the readHTML line fails the pin guard at load. Unmutated: editor-browser 17/17 (13.3 s), editor 5/5, editor-provenance 6/6, no skips; every mutant restored, git status empty. The earlier #784 BUILD-LOG and SESSIONS lines are on 1bf83078b, not on this base, so a merge keeps both appends. No push, queue or PR action.
+
+2026-11-03 | Lead Codex, request-to-product discovery (Vikunja #797, Gitea #1839) | Before: pomodoro request has no product project/approved requirement; Console resolves only grant decisions with buttons although REQ-WEB-2 requires each option; broker and task adapter both use Stack PRD 1.19 baked catalogue. Scope: prepare the concrete lifecycle/authority design before any schema or role change. No runtime/config change. Claude Sonnet discovery delegate failed 503 auth_unavailable/account rate limit; no provider substitution.
+
+2026-11-03 | Lead Codex, request-to-product design handoff (Vikunja #797, Gitea #1839) | After: docs/plans/2026-11-03_request-to-product-design.md proposes general Console answers first, durable pre-task intake and three modes, typed project bootstrap, project-scoped approved PRDs and automatic continuation through reviewed delivery; original pomodoro is the acceptance case. Opus independent builder check also failed Claude rate limit; lead self-check only, no independent approval. Await owner decision on concrete authority/schema scope and temporary GPT implementation delegation while Claude is unavailable. Documentation only; product behavior and acceptance not claimed.

docs/SESSIONS.md

@@ -1979,3 +1979,4 @@ are never rewritten or removed; corrections are new entries.
 2026-11-03 | Claude (sub-agent of Mosaic Stack lead c5c1e8ba) | editor-browser :154 under Chromium 156 (Vikunja #784) | 0c6aa1a1e on t3/editor-chromium-156 (base 1ff45c4ad): test-only; the page's CSP record sets aside the paste's inert-parse script-src-attr reports, keyed on editor.js readHTML's parse line and target document; a new test shows live inline handlers still fail quiet(); editor-browser 17/17, editor plus editor-provenance 11/11, no skips; 4 mutants killed; no push, queue or PR action.
 2026-11-03 | Claude (sub-agent of Mosaic Stack lead c5c1e8ba) | Vikunja #415 and #416, .53 and .54 Console writes | bd79daffd on t3/console-writes-53-54 (base 1ff45c4ad): factory takes the paired --sso --send with a console.sso check before any unit write; .53 business document on provider proxy, route anthropic, account factory/proxy; library --send not done (needs the #385 refusal reverted, returned to the lead); cli case2-unit 88, stack-upgrade 25, case1-accept 53, business 8, 3 and 3, no skips; 2 mutants killed; no push, queue or PR action.
 2026-11-03 | Claude (sub-agent of Mosaic Stack lead c5c1e8ba) | editor-browser paste test round 2 (Vikunja #784) | e71222d1a on t3/784-r2 (base 0c6aa1a1e): test-only; a MutationObserver on the live document records handler-bearing elements entering the page and h.quiet() asserts none, so the CSP filter cannot hide an attach-then-remove; the reviewer's mutation now fails the paste and live-handler tests; the four earlier mutants still killed; editor-browser 17/17, editor 5/5, editor-provenance 6/6, no skips; no push, queue or PR action.
+2026-11-03 | Lead Codex GPT-6.1 Sol, resumed c5c1e8ba | Jason request-to-product intake, general Console decision buttons and autonomous product workflow (#797, Gitea #1839) | Recovered owner decisions and current code; queue next sage returned historical ledger row 7, direct owner request takes priority; drafted scoped design and acceptance, both Claude research/review delegates failed account rate limit; no product/host/config/role change, no provider substitution; owner alignment and coding-model exception outstanding.

docs/plans/2026-11-03_request-to-product-design.md

@@ -0,0 +1,250 @@
+# Request to product: intake, decisions and autonomous delivery
+
+Status: proposed, not approved or implemented. Prepared 2026-11-03 against
+`refactor` `7024e35f5`. Tracking: Vikunja #797 and
+[Gitea #1839](https://git.mosaicstack.dev/mosaicstack/stack/issues/1839).
+
+## Owner intent
+
+Jason's 2026-11-03 request follows the failed pomodoro delegation on .53.
+A missing project or PRD must start the planning workflow. Agents must carry
+ideation through requirements, implementation, review and a usable result.
+When a request is unattached, offer three choices: a new autonomous project,
+a new project with guided questions, or an existing project. Decision options
+must have working Console answer buttons. Jason also wants an agent to operate
+the system autonomously. These are product requirements, not instructions to
+misclassify a pomodoro timer as a Mosaic Stack requirement.
+
+Earlier owner decisions still supply the operating boundaries: trusted actions
+within role guardrails, user-selected manual mode, and the existing hard waits.
+This proposal extends the paths that execute authorized work. It does not
+create a global automatic approval setting.
+
+## Findings
+
+- REQ-WEB-2 already requires one button per decision option. Today
+  `packages/bus/src/broker.mjs` `#consoleResolution` accepts only a human-routed
+  `credential.mint` request with a grant binding and two choices. The Console's
+  `decisionView` consequently offers terminal Copy commands for other decisions.
+  This is an implementation gap against an approved requirement.
+- Both the broker and `packages/tasks/src/verbs.mjs` load the single baked
+  `packages/tasks/requirements.json`, currently Mosaic Stack PRD 1.19. Adding
+  a product PRD document alone cannot make its requirements usable by tasks.
+- `roles/pm.md` tells the PM to raise `prd.approve` when no requirement fits.
+  It has no discovery-to-project workflow or executable PRD activation step.
+  A pre-task decision must currently be non-blocking: blocking decisions require
+  an existing tracker task. Intake needs its own durable waiting state.
+- `project.create` groups chat threads. A business project, its local records
+  repository, its code checkout and its tracker mapping are separate objects.
+  `mosaic project init` requires an already declared business project, and the
+  organization writer explicitly protects the project mapping.
+- `prd.approve` already routes to an arbiter when it cites the current
+  human-authored spec. A raise routed back to its own role instead goes to the
+  human. Autonomous planning must select a distinct, authorized reviewer.
+- Decision closure already notifies the raising role. That is useful machinery
+  to extend; it does not yet constitute a durable request-to-product controller.
+
+## Approach and tradeoff
+
+Recommend extending the existing broker, project records, tracker adapter and
+Console decision endpoints. They already own authority, attribution and audit.
+Implement the workflow as explicit state transitions with durable continuations,
+not as instructions that depend on an agent remembering to retry.
+
+Two alternatives were considered. A prompt-only change would be small but cannot
+provision projects or pass the actual requirement validator. A separate workflow
+service would duplicate decisions and recovery state. Neither satisfies this
+increment as well as extending the existing machinery. This recommendation is
+the lead's proposal, not an owner-approved implementation choice yet.
+
+## User experience
+
+Capture the original request and determine whether its project and approved
+requirements are known. If they are, continue under the project's chosen mode.
+If not, present one concise intake decision. For the example:
+
+> This request is not attached to a product project and has no approved PRD.
+> How should we handle the single-file pomodoro timer?
+
+| Answer button | What happens |
+| --- | --- |
+| New project — autonomous | Agents clarify by making recorded assumptions, draft and review the PRD, plan, build, test and review the MVP within the displayed scope. |
+| New project — guided | Agents conduct a short question-and-answer session and return product decisions and the PRD to the user through the Console. |
+| Add to existing project | Show an authorized project picker, then check the request against that project's PRD and continue under its mode. |
+
+Show the proposed project name, the original intent and concrete resource plan
+before confirming a new project. The default initial intent is the human's
+original request, not an agent-written replacement for it. Any generated intent
+text must be displayed and confirmed by the user before being committed as human
+specification. Cancellation leaves the request available without creating work.
+An existing project with a missing or insufficient PRD follows discovery and
+revision; attachment does not manufacture a matching requirement.
+
+Questions allow option buttons and a text answer where needed. The default
+decision path requires no terminal. Signed-out or deliberately read-only
+Consoles explain their state; an authorized writable Console exposes every
+open decision option routed to that user, including choices other than yes/no.
+Grant requests keep their existing concrete rights summary and confirmation.
+
+## Lifecycle and durable state
+
+Maintain a versioned intake record linked to the original human input event,
+business, request, selected project, mode, owner and current continuation.
+Use the existing append-only stores; derived current state may be rebuilt from
+events. This is operational data, not another system configuration.
+
+The successful path is capture, project selection, discovery, PRD draft, PRD
+review/approval, task planning, implementation, verification, review and delivery.
+A waiting state records the exact question, decision, launch condition or missing
+resource and the step to resume. Discovery and intake do not require a fictional
+implementation task or a fabricated requirement ID.
+
+Transitions bind to a request and expected revision. A repeated message, double
+click, repeated resolution notice or restart must not duplicate a project, PRD,
+task or delivery. An uncertain external write is reconciled by reading its
+recorded result, never blindly repeated. Keep irreversible evidence intact and
+record partial provisioning steps so recovery can finish them safely.
+
+When a decision closes, or an authorized launch prerequisite becomes available,
+the responsible role resumes automatically through the chief's existing launch
+and limits path. A refusal names the unavailable prerequisite. An unsupported
+setup becomes one actionable Console decision or error with a resume path;
+it does not turn the human into the messenger between agents.
+
+## Project bootstrap
+
+One protected bootstrap path connects the selected chat project to a declared
+business project, separate code and records paths, an approved intent spec,
+tracker identity and the roles needed for delivery. Use the current config and
+validators. Do not loosen `organization.write` into arbitrary project-map edits.
+Add a typed, revision-checked operation dedicated to the approved bootstrap.
+
+The selection confirmation binds the exact project/resource plan and mode.
+Create paths only in the configured managed area and refuse collisions, symlinks
+and overlapping ownership. Existing projects and tracker associations can be
+selected and reused only when authorized. Each resource has an idempotent
+provisioning receipt; retry resumes the same resource rather than creating a
+second one.
+
+The first supported full delivery route uses the existing software-factory
+repository and tracker integration, with a distinct product project and its own
+requirement namespace. The executor must either provision the required code
+repository, working/fork arrangement and tracker project using configured service
+authority, or surface the precise missing grant through the existing grant
+workflow. No SSH or manual file editing is the normal user path. New accounts,
+new access grants or other hard-wait effects still use their protected executors.
+The pomodoro acceptance run cannot be declared complete while this setup remains
+a manual prerequisite or silently writes into Mosaic Stack's product scope.
+
+Bootstrap begins from a human choice or an explicit, previously approved project
+creation mandate. The mandate binds an allowed resource area, existing service
+identities, role scope and current limits, can be revoked, and records the agent
+that exercised it. Creating a mandate is a user control. Its exact new action
+and schema must be reviewed and explicitly routed in the proposed PRD amendment
+before implementation; REQ-WAIT-3 otherwise keeps a new action gated.
+
+## PRD authority and requirement validation
+
+Keep the human's intent spec distinct from the product PRD. PM agents can draft
+versioned PRDs and requirement records. In autonomous mode the PM requests a
+separate authorized review: initially a technical `prd.approve` raise to the CTO,
+citing the human-approved project spec. The PM must not resolve its own approval.
+Guided mode returns the exact draft and open questions to the human for approval.
+
+Bind approval to the business, product project, PRD version/content commit,
+requirement set and current intent spec. An edit after approval needs a fresh
+approval. Merely writing `status: accepted` in an agent-controlled JSON file
+does not publish a requirement or grant authority. Record who authored, reviewed
+and approved each version, then activate the approved snapshot through validated
+stack code.
+
+Make both `list_requirements` and task creation consult that same project-scoped
+approved snapshot. Requirement identity includes its business/project and PRD
+revision as well as its ID. Reject a requirement from another project, a draft,
+an unapproved revision, a revoked delegation or an ambiguous project context.
+Include source version/commit in task evidence. Preserve the built-in Mosaic
+Stack catalogue for the Stack project and existing clients; never use it as a
+universal fallback for a newly selected product project.
+
+## Autonomous operation and decisions
+
+The chosen mode applies to product choices and PRD revisions within the approved
+intent and current role authority. Agents operate through typed broker tools,
+which record the actual role/run. Human Console answers use the signed-in
+identity and existing session/origin checks. Working buttons do not depend on
+proving that a person physically clicked them, and no new automation-detection
+barrier is proposed.
+
+Retain the current protected-action gates. Autonomous product mode does not
+approve spending, external messages, grants, deployment or protected pushes.
+When such a step is needed, the agent prepares the exact action, surfaces its
+working Console answer buttons and resumes automatically after resolution.
+Changing mode or revoking a mandate takes effect at the next action and is
+audited. Delivery of a reviewed artifact is distinct from deployment.
+
+## Implementation order and acceptance
+
+1. Generalize Console decisions under existing REQ-WEB-2. Render every eligible
+   option, preserve grant confirmation and summaries, and extend server-side
+   preview/resolve validation to the full option set. Test actual signed-in
+   click-to-resolution, stale/closed decisions, session expiry, duplicate answers
+   and uncertain outcomes; verify the existing grant executor still runs once.
+2. Add durable intake, the three mode choices, project picker and bootstrap.
+   Verify pre-PRD intake needs no tracker task. Test restart/replay, cancellation,
+   resource collisions, partial setup and missing grants. Inspect exact project
+   and tracker associations rather than accepting a chat project as sufficient.
+3. Add scoped PRD activation, both validation paths and role continuations.
+   Test autonomous distinct-role approval, guided Q&A and human approval, attaching
+   to an existing project, draft/cross-project rejection, mode changes, revocation
+   and no task creation before approved product requirements exist.
+4. Run the original pomodoro request end to end in an isolated configured test
+   instance. Select autonomous mode once. Agents create the product PRD, tasks,
+   build and test the artifact, obtain an independent review and deliver a
+   self-contained HTML file. Proposed small MVP defaults: 25-minute work and
+   5-minute break, start/pause/reset and a phase-end cue, with no external assets.
+   These defaults are proposed product decisions for that project, not preexisting
+   human requirements. Guided and attachment branches also get integration tests.
+   The result includes requirement/PRD/task/commit/review evidence and an openable
+   artifact; no human forwards messages or runs decision commands.
+
+Run the affected bus, tasks, project, business, CLI and WebUI suites, plus the
+actual Console browser flow. Keep reviews and gates proportional to the owner’s
+first-usable mandate. Deployment to .53/.54 requires its own concrete window and
+authorization; this design stage changes no running instance.
+
+## Proposed PRD delta and decisions for the owner
+
+REQ-WEB-2 is already approved and needs implementation rather than another
+requirement. The lifecycle needs a reviewed additive PRD version covering:
+
+- Pre-task intake, linked to the human request, with the three project choices
+  and a durable resume path when project or PRD context is absent.
+- Typed project bootstrap and optional explicit project-creation mandates within
+  configured resource/service authority, with a concrete confirmation and audit.
+- Autonomous versus guided product decision modes, exact-version PRD activation,
+  distinct-role review, revocation and scope enforcement.
+- Project-scoped requirement validation in broker and tracker, with compatibility
+  for current Mosaic Stack tasks and no cross-project fallback.
+- Automatic coordination through reviewed artifact delivery, including visible
+  refusals and restart recovery, without human message relay.
+
+The owner needs to accept or correct this concrete scope, especially the
+bootstrap mandate and autonomous PRD authority. The existing approved PRD is not
+edited or declared superseded by this draft.
+
+Jason requested Claude coding delegates and prefers cross-provider review.
+A Sonnet 5.5 xhigh discovery delegate failed on 2026-11-03 with
+`503 auth_unavailable`, caused by an account rate limit. No replacement provider
+has been selected. A temporary authorization for GPT-6.1 Sol delegates would
+allow implementation while Claude is unavailable; otherwise delegated coding
+resumes when the requested Claude access is restored.
+
+## Review status
+
+An Opus 5.5 builder-check delegate also failed with the same account rate limit.
+The lead checked the proposal against the current implementation and amended it
+to cover both requirement validators, PM self-routing, the protected project map
+and the pre-task decision constraint. This is a self-check, not independent
+approval. Independent review and all product acceptance tests remain outstanding.
+No production code, role policy, approved PRD, instance configuration or running
+service changed during this design stage.