Address Copilot review on PR #350: note that default_backend selects a crawl backend and passive extractors such as jsfinder are not selectable there; model scope_decision as a decision plus reason in both the field list and the JSON example; add an illustrative scope_entries example and clarify when allowed_hosts applies.
Refs #336
Add examples/proposals/headless_crawler_integration.md, a docs-only RFC proposing an optional, tool-agnostic crawler / URL discovery capability for PentAGI agents. Candidate backends are katana, crawlergo, rad, and jsfinder, framed as candidates with no mandatory default. The RFC keeps dictionary fuzzing (ffuf/dirsearch) unchanged, defines structured discovery artifacts (URLs, forms, parameters, JavaScript endpoints, status codes, source page, depth, scope decision), and keeps crawler URL discovery separate from the BrowserOS MCP interactive browser backend.
Refs #336
Add examples/proposals/kubernetes_deployment.md, an RFC-style design
surface responding to the Kubernetes deployment request in #324. The
document is docs-only: no Helm charts, manifests, operator, compose,
installer, or environment-variable changes, and it does not claim
Kubernetes is supported today.
It records the current Compose/installer deployment assumptions, maps
each one (secrets/config, volumes, service discovery, ingress/TLS,
health checks, network policies, the Docker-socket flow executor,
observability, image overrides, migrations) to candidate Kubernetes
equivalents, and proposes an incremental, docs-first path with open
questions, security/operational considerations, and a test/validation
strategy. The hardest item -- the Docker-socket worker executor -- is
laid out as candidate options without choosing one, and keeps flow
lifecycle explicit and inspectable per the #268 review lesson.
Refs #324
- Drop the hard-coded provider count to avoid doc drift as providers are
added; list the current provider types instead.
- Use the ADC-specific command (gcloud auth application-default login)
rather than the ambiguous 'gcloud login'.
- Reference the enum-swap migration pattern generically under
backend/migrations/sql/ instead of a single timestamped filename that
may be renamed or squashed.
Issue #321 requests a native Vertex AI provider with service-account /
ADC auth, opened after #310 clarified Vertex is not supported today. The
issue carries a full implementation outline and four open questions, and
the author asks for direction on adapter strategy and Gemini-vs-Claude
scope before implementing.
Add examples/proposals/vertex_ai_provider.md, a planning RFC that frames
the work before any code is written:
- Distinguishes the current options (AI Studio gemini, direct Anthropic,
AWS Bedrock, and the custom OpenAI-compatible LiteLLM proxy workaround)
from the proposed native vertex provider.
- Recommends a staged approach: v1 Gemini-on-Vertex with ADC /
service-account auth; Claude-on-Vertex deferred to a maintainer
decision, noting it likely belongs on the Anthropic adapter (Vertex
auth/endpoint mode) rather than the Gemini-shaped path because the
message schema differs.
- Models auth on the existing Bedrock multi-auth precedent (ADC default
chain plus service-account file), and flags that service-account JSON
is sensitive and must be file-mounted/secret-managed, never pasted into
UI or logs.
- Captures config/migration touch points (provider checklist, REST
Valid() whitelist, PROVIDER_TYPE enum-swap migration) so the eventual
implementation size is clear, and restates the issue's open questions.
Docs/RFC only. No code, schema, migration, generated, frontend, or
provider runtime files are touched, and no new env vars or types are
added; every VERTEX_* key and type named is labeled as a candidate. No
overlap with the provider files in open PR #328.
Updated the Qwen agent configuration to include `extra_body` parameters for thinking control across various models. Added `enable_thinking` and `preserve_thinking` options for reasoning agents, while utility agents have `enable_thinking` set to false. Adjusted the Qwen client initialization to support these new configurations. Updated test report to reflect changes in success rates and latencies.
DeepSeek V4 thinking mode defaults to enabled on both deepseek-v4-flash
and deepseek-v4-pro; non-thinking behavior requires an explicit toggle.
Per official docs, in thinking mode temperature/top_p/presence_penalty/
frequency_penalty are ignored, so the existing Flash role sampling knobs
would have been silently no-ops without the toggle.
Add extra_body.thinking.type=disabled to the five non-thinking Flash
roles so deepseek-v4-flash actually runs in non-thinking mode and
honors the role's temperature/top_p settings:
- simple, simple_json, adviser, searcher, enricher
Pro roles (primary_agent, assistant, generator, refiner, reflector,
coder, installer, pentester) intentionally keep thinking enabled (the
V4 default) for reasoning, tool-use, and security analysis.
PentAGI provider config already supports extra_body as a first-class
yaml field on AgentConfig and forwards it through openai.WithExtraBody,
which the vxcontrol langchaingo fork serializes at the top level of the
Chat Completions request - the same pattern Kimi uses for tool_choice.
No code, schema, or LiteLLM prefix changes required.
Touches:
- backend/pkg/providers/deepseek/config.yml (embedded production config)
- examples/configs/deepseek.provider.yml (user-facing example)
No change to role-to-model mapping, model metadata, pricing, README
wording, LiteLLM prefix, unrelated providers, lifecycle, queues, or
installer flow.
- Update model descriptions to reflect V4 1M context window (up to 384K output)
instead of legacy 128K wording in models.yml and README.
- Split Flash and Pro pricing per official DeepSeek API docs:
- deepseek-v4-flash: input 0.14 / output 0.28 / cache_hit 0.0028 per 1M tokens
- deepseek-v4-pro: input 0.435 / output 0.87 / cache_hit 0.003625 per 1M tokens
- Apply per-role price split across all 13 role configs in both the embedded
config.yml and the user-facing examples/configs/deepseek.provider.yml.
- Replace stale "cache pricing is 10% of input cost" claim in the README,
which no longer holds for either V4 model.
- No change to LiteLLM prefix behavior, role-to-model mapping, lifecycle,
queues, GraphQL schema, migrations, frontend, or installer flow.
The DeepSeek provider config still defaulted to the legacy
`deepseek-chat` and `deepseek-reasoner` model names, which the
upstream DeepSeek API has announced for deprecation on 2026-07-24.
A first-run install therefore breaks once the legacy names are
removed.
Swap the defaults to the current DeepSeek V4 family:
- non-thinking roles use `deepseek-v4-flash`
- reasoning-heavy roles use `deepseek-v4-pro`
The change is limited to the embedded `config.yml` / `models.yml`
inside `backend/pkg/providers/deepseek`, the matching example at
`examples/configs/deepseek.provider.yml`, the `DeepSeekAgentModel`
fallback constant in `deepseek.go`, and three doc references
(README.md, backend/docs/config.md, backend/docs/llms_how_to.md)
plus one installer help string in
`backend/cmd/installer/wizard/locale/locale.go`. LiteLLM prefix
behavior is untouched.
- Included two new provider YAML files for Qwen 3.6 35B models: `vllm-qwen3.6-35b-a3b-fp8-no-think.provider.yml` and `vllm-qwen3.6-35b-a3b-fp8.provider.yml`.
- Updated Dockerfile to copy the new configuration files into the appropriate directory.
- 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>
- Added new provider configurations for vLLM Qwen 3.6 in both thinking and non-thinking modes.
- Updated the Dockerfile to include the new configuration files for vLLM Qwen 3.6 and ensure proper setup for deployment.
mason5052