- Reword PR #268 references to talk about review feedback rather
than the PR being rejected.
- Clarify host.docker.internal availability: not universally provided
by the core compose stack; Docker Desktop typically resolves it,
while Linux/operator-managed compose stacks may need an explicit
extra_hosts: host.docker.internal:host-gateway entry or another
controlled endpoint.
- Make the safe initial Burp example unambiguously read-only: drop
start_active_scan from the illustrative allowlist and call out
that active capabilities belong to a later, explicitly gated
milestone with scope and approval controls.
- Rephrase the awkward 'PentAGI must not be inferred...' sentence
for clarity.
Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
Address Copilot review feedback on PR #306:
- Lifecycle diagram: show running <-> waiting (waiting is a paused state that resumes to running when user input arrives) and document that both running and waiting can reach the terminal statuses finished or failed.
- Replace overloaded 'finished' wording with explicit 'terminal' semantics throughout. finished and failed remain distinct terminal statuses; the queue and webhook layers treat both as terminal.
- Align webhook event names with status terminology: flow.finished for success, flow.failed for failure. Update payload example accordingly and note the failed-flow shape.
Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
Proposes a design direction for native flow concurrency control and
completion notifications. The RFC follows the maintainer's relocated
proposal pattern at examples/proposals/<topic>.md and explicitly
builds on the lessons from PR #268 (rejected because the in-memory
queue was hidden lifecycle state).
The RFC covers:
- Goals limited to capping concurrent flows, persisting queued flows
as first-class lifecycle, replacing external polling with at-least-
once webhooks, and preserving the existing createFlow contract.
- Non-Goals that explicitly forbid hidden in-memory queues, multi-
tenant scheduling, generic event bus features, and changing the
meaning of 'finished' for tasks/subtasks/toolcalls.
- Design Principles for persistence, visibility, manageability,
explicit promotion, clear finished semantics, and at-least-once
delivery.
- A proposed concurrency model with a new persisted 'queued' status,
a single MAX_CONCURRENT_FLOWS knob, an explicit promoter, and
full UI/API visibility plus user cancellation.
- A proposed completion webhook model with per-flow and global URLs,
HMAC-SHA256 signatures, persisted deliveries, bounded retries,
and SSRF mitigations.
- Storage and API surface sketches that do not commit to a final
schema.
- Open Questions covering per-user limits, blocking semantics on
createFlow, signature alignment with the issue #235 receipt
direction, and behavior of resources/uploads against queued flows.
- A Suggested First Milestone that lands the queue end-to-end before
webhooks, to keep PR sizes reviewable.
This is documentation only. No runtime code, schema, GraphQL, REST,
or UI behavior changes here.
Refs #298
Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
Dmitry Ng