langgenius · RiskeyL · Apr 29, 2026 · Apr 29, 2026 · Apr 29, 2026 · Apr 29, 2026
@@ -17,6 +17,18 @@ Read these shared guides:
 2. `writing-guides/formatting-guide.md`
 3. `writing-guides/glossary.md`
 
+## Source of Truth: `docker/.env.example`
+
+The doc mirrors `docker/.env.example`, the supported self-host knob surface.
+
+| Var location | Action |
+|---|---|
+| In `.env.example`, uncommented | Document. |
+| In `.env.example`, commented (`#FOO=bar`) | Document; add to **Verifier false positives** in `ignored-vars.md` (the verifier can't parse defaults from comments). |
+| Only in `api/configs/` Pydantic, not in `.env.example` | **Don't document.** Upstream-deferred; file a PR adding it to `.env.example` first. |
+
+The verifier's "extra in docs" signal is not an escape hatch. Never suppress it for Pydantic-only vars via `ignored-vars.md`.
+
 ## Four-Step Process
 
 **Pull the latest Dify code** before tracing. In the Dify codebase directory:
@@ -143,7 +155,7 @@ Some variables in `.env.example` are deliberately not documented (Cloud-only, ex
 
 - Remove a variable from the docs as Cloud-only → add it under **Cloud-only (SaaS)** in `ignored-vars.md`.
 - Skip documenting an experimental or internal flag → add it under **Experimental / internal**.
-- Document a supported variable whose `.env.example` entry is commented out → add it under **Verifier false positives**.
+- Document a supported variable whose `.env.example` entry is **commented out** (e.g., `#FOO=bar`) → add it under **Verifier false positives**. This bucket is **only** for vars that exist in `.env.example` in commented form. Do not use it to suppress verifier signal for vars that are absent from `.env.example` entirely — those are upstream-deferred (see [Source of Truth](#source-of-truth-docker-env-example)) and must not be documented.
 
 Every entry must include a source reference (PR, commit, or audit date).
 

@@ -287,9 +287,9 @@ This is primarily a developer/debugging tool. Not recommended for production due
 
 **Key code locations:**
 - Definition: `api/configs/deploy/__init__.py`
-- Workflow debug: `api/core/workflow/workflow_entry.py`
+- Workflow debug: `api/core/workflow/workflow_entry.py` (entry); `graphon/src/graphon/graph_engine/layers/debug_logging.py` (DebugLoggingLayer; lives in the graphon repo)
 - Tool callbacks: `api/core/callback_handler/agent_tool_callback_handler.py`
-- LLM logging: `api/dify_graph/model_runtime/model_providers/__base/large_language_model.py`
+- LLM logging: `graphon/src/graphon/model_runtime/model_providers/base/large_language_model.py` (graphon repo)
 
 ---
 
@@ -1479,3 +1479,35 @@ The existing entry near line 937 describes behavior correctly, but the stated de
 ### POSTGRES_MAX_CONNECTIONS — default correction
 
 Covered in the "PostgreSQL / MySQL Performance Tuning Variables" section. `docker/.env.example` bumped the default from `100` to `200` upstream (`docker-compose.yaml` passes it as `-c max_connections=${POSTGRES_MAX_CONNECTIONS:-200}` to the Postgres container). The higher default is safer for Dify's multi-worker + Celery + async-task traffic shape; operators can still lower it on constrained hosts.
+
+---
+
+### CREATORS_PLATFORM_FEATURES_ENABLED, CREATORS_PLATFORM_API_URL, CREATORS_PLATFORM_OAUTH_CLIENT_ID
+
+Creator Center is the submission portal where users upload Dify apps as DSL templates. Submitted templates are reviewed and, once approved, listed on Dify Marketplace. The console's **Publish to Marketplace** button (i18n key `common.publishToMarketplace` in `web/i18n/{en-US,zh-Hans,ja-JP}/workflow.json`) drives this flow.
+
+**Flow:**
+
+1. User clicks **Publish to Marketplace** in the app builder. The button is gated on `systemFeatures.enable_creators_platform` (frontend: `web/app/components/app/app-publisher/index.tsx`).
+2. Frontend calls `POST /apps/{app_id}/publish-to-creators-platform`.
+3. Endpoint (`api/controllers/console/app/app.py: AppPublishToCreatorsPlatformApi`) returns 403 when `CREATORS_PLATFORM_FEATURES_ENABLED` is false. Otherwise it exports the app DSL via `AppDslService.export_dsl(include_secret=False)`.
+4. `core/helper/creators.upload_dsl()` POSTs the DSL to `{CREATORS_PLATFORM_API_URL}/api/v1/templates/anonymous-upload` and receives a `claim_code`.
+5. `get_redirect_url()` builds the redirect with `?dsl_claim_code=...`. If `CREATORS_PLATFORM_OAUTH_CLIENT_ID` is non-empty, it also signs an OAuth authorization code via `OAuthServerService.sign_oauth_authorization_code(client_id, user_account_id)` and adds `&oauth_code=...`.
+6. Frontend opens the redirect URL in a new tab, taking the user into Creator Center to fill in template details.
+
+**Behavior by var state:**
+
+- `CREATORS_PLATFORM_FEATURES_ENABLED=false`: button hidden, console API returns 403. Self-hosters use this to remove the one-click publish path.
+- `CREATORS_PLATFORM_API_URL` overridden: only meaningful with a self-hosted Creator Center instance. Default `https://creators.dify.ai`.
+- `CREATORS_PLATFORM_OAUTH_CLIENT_ID` empty (default): anonymous upload — the receiving Creator Center cannot attribute the template to the publishing user.
+
+**Key code locations:**
+
+- Pydantic config: `api/configs/feature/__init__.py` (`CreatorsPlatformConfig`)
+- Service exposure: `api/services/feature_service.py` (`enable_creators_platform`)
+- Console controller: `api/controllers/console/app/app.py` (`AppPublishToCreatorsPlatformApi`)
+- Upload helper: `api/core/helper/creators.py`
+- Frontend trigger: `web/app/components/app/app-publisher/index.tsx`
+- UI labels: `common.publishToMarketplace` in `web/i18n/{en-US,zh-Hans,ja-JP}/workflow.json`
+
+**Naming note:** Env var prefix is `CREATORS_PLATFORM_*` and the backend Pydantic class is `CreatorsPlatformConfig`, but the user-facing product name is **Creator Center** and the UI button reads "Publish to Marketplace" (templates appear on Marketplace after Creator Center review). Use "Creator Center" in user-facing prose; the prefix is a backend-only artifact.
@@ -10,38 +10,62 @@ Pre-writing research that combines codebase analysis with community feedback to
 ## Before Starting
 
 1. Ask the user which feature, node, or area to research.
-2. Confirm which branch of the Dify codebase to investigate (default: `main`).
+2. Confirm which branch to investigate (default: `main` for both repos).
 3. Check if the user has a specific doc page in mind for the rewrite.
 
-**Codebase location**: The Dify codebase is typically available as an additional working directory. If not, ask the user for the path.
+**Codebase location**: Dify's backend logic is split across two repos.
 
-**Pull latest code** before investigating. In the Dify codebase directory:
+| Repo | Local path (typical) | GitHub | Owns |
+|:-----|:---------------------|:-------|:-----|
+| dify | `~/Documents/Work/Dify Repo/dify` | `langgenius/dify` | API, web, orchestration, integration nodes (Agent, Knowledge, Datasource, Trigger), Celery tasks |
+| graphon | `~/Documents/Work/Dify Repo/graphon` | `langgenius/graphon` | Graph engine, runtime, model_runtime, built-in workflow nodes, HTTP/file/protocols |
+
+If either is missing as a working directory, ask the user for the path.
+
+**Pull latest code** before investigating. Run in each repo directory:
 ```bash
 git fetch origin && git checkout main && git pull origin main
 ```
-If the user specified a different branch, substitute accordingly.
+If the user specified a different branch for either repo, substitute accordingly.
 
-**GitHub repo**: `langgenius/dify`
+**Version pinning matters.** dify pins graphon to a specific version. Before reading graphon code, check the pinned version and verify against that tag, not graphon `main`:
+```bash
+grep '"graphon' ~/Documents/Work/Dify\ Repo/dify/api/pyproject.toml
+# e.g. "graphon~=0.2.2" → check out v0.2.2 in graphon, not main
+```
+If you read graphon `main` and document behavior that ships only in an unreleased graphon version, the docs will not match what users see. When in doubt, ask the user whether to verify against the pinned version or graphon `main` (the latter is appropriate when documenting something the user knows is about to ship).
 
 ## Research Process
 
 Run Phase 1 and Phase 2 in parallel using subagents where possible.
 
 ### Phase 1: Codebase Investigation
 
-Locate and read the source code for the feature. Cover all three layers:
+First decide which repo owns the backend implementation:
 
-**Backend implementation** — Find the core logic. For workflow nodes, check `api/dify_graph/nodes/<node_name>/`. Read:
+| Feature class | Repo | Path |
+|:--------------|:-----|:-----|
+| Built-in workflow nodes (LLM, Code, HTTP Request, If/Else, Loop, Iteration, Parameter Extractor, Document Extractor, List Operator, Variable Aggregator/Assigner, Question Classifier, Template Transform, Tool, Start/End/Answer, Human Input) | graphon | `src/graphon/nodes/<node_name>/` |
+| Integration nodes (Agent, Knowledge Retrieval, Knowledge Index, Datasource, Trigger Plugin/Schedule/Webhook) | dify | `api/core/workflow/nodes/<node_name>/` |
+| Graph engine, runtime state, variable pool, command channels, layers | graphon | `src/graphon/graph_engine/`, `src/graphon/runtime/` |
+| Model runtime, model providers, LLM/embedding/rerank invocation | graphon | `src/graphon/model_runtime/` |
+| Workflow orchestration in Flask routes and Celery tasks | dify | `api/controllers/`, `api/tasks/`, `api/services/` |
+| RAG and knowledge retrieval logic | dify | `api/core/rag/` |
+| Tool plugins | dify | `api/core/tools/` |
+
+Then locate and read the source code, covering all three layers:
+
+**Backend implementation** — Find the core logic in the repo identified above. Read:
 - The main node class (execution logic, `_run()` method)
 - Entity definitions (data models, enums, supported types)
 - Any template or streaming logic
 
-**Frontend UI** — Find the React components. For workflow nodes, check `web/app/components/workflow/nodes/<node_name>/`. Read:
+**Frontend UI** — Find the React components in the dify repo (the web frontend was not split out). For workflow nodes, check `web/app/components/workflow/nodes/<node_name>/`. Read:
 - Panel component (what configuration options users see)
 - Type definitions (data shape)
 - Default values and validation rules
 
-**API surface** — Trace how the feature's output reaches the API response. Check controllers, response converters, and serialization.
+**API surface** — Trace how the feature's output reaches the API response. Check controllers, response converters, and serialization (all in dify).
 
 Produce a summary of:
 - What the feature does (based on code, not existing docs)
@@ -56,13 +80,19 @@ Flag any behavior inferred from code rather than observed in the running product
 
 Search for user-reported problems and questions across these channels:
 
-**GitHub Issues** — Run multiple searches with varied terms:
+**GitHub Issues** — Run multiple searches with varied terms. Always search dify; also search graphon when the feature is a built-in workflow node, the graph engine, runtime, or model_runtime:
 ```bash
 gh issue list --repo langgenius/dify --search "<feature name>" --limit 30
 gh issue list --repo langgenius/dify --search "<alternative name>" --limit 30
 gh search issues "<feature> <context>" --repo langgenius/dify --limit 20
+
+# For built-in nodes, engine, runtime, or model_runtime, also:
+gh issue list --repo langgenius/graphon --search "<feature name>" --limit 30
+gh search issues "<feature> <context>" --repo langgenius/graphon --limit 20
 ```
 
+End users typically file in dify even for graphon-owned behavior; graphon's tracker tends to hold engineering-side reports. Check both to avoid missing pain points.
+
 **GitHub Discussions** — Search for related discussion topics:
 ```bash
 gh api "repos/langgenius/dify/discussions?per_page=30" --jq '.[] | select(.title | test("<pattern>"; "i"))'

@@ -102,17 +102,21 @@ Also check: Pydantic models and `fields/` serializers used by Service API contro
 
 Read the PR description for context. Map changed source paths to likely doc areas:
 
-| Source path pattern | Likely doc area |
-|---|---|
-| `api/core/workflow/nodes/` | `en/use-dify/workflow/nodes/` |
-| `api/core/rag/` | `en/use-dify/knowledge/` |
-| `api/core/model_runtime/` | `en/use-dify/model-providers/` |
-| `api/core/tools/` | `en/use-dify/tools/` or workflow tool node docs |
-| `api/core/agent/` | `en/use-dify/build-apps/agent.mdx` |
-| `api/core/app/` | `en/use-dify/build-apps/` |
-| `web/app/components/` | UI-related docs (check PR description for specifics) |
-| `docker/`, deployment configs | `en/getting-started/install/` |
-| `api/configs/` | Configuration/environment variable docs |
+| Repo | Source path pattern | Likely doc area |
+|---|---|---|
+| dify | `api/core/workflow/nodes/` (integration nodes only: agent, knowledge, datasource, trigger) | `en/use-dify/workflow/nodes/` |
+| dify | `api/core/rag/` | `en/use-dify/knowledge/` |
+| dify | `api/core/tools/` | `en/use-dify/tools/` or workflow tool node docs |
+| dify | `api/core/agent/` | `en/use-dify/build-apps/agent.mdx` |
+| dify | `api/core/app/` | `en/use-dify/build-apps/` |
+| dify | `web/app/components/` | UI-related docs (check PR description for specifics) |
+| dify | `docker/`, deployment configs | `en/getting-started/install/` |
+| dify | `api/configs/` | Configuration/environment variable docs |
+| graphon | `src/graphon/nodes/` (built-in nodes: llm, code, http_request, if_else, loop, iteration, parameter_extractor, document_extractor, list_operator, variable_aggregator/assigner, question_classifier, template_transform, tool, start/end/answer, human_input) | `en/use-dify/workflow/nodes/` |
+| graphon | `src/graphon/model_runtime/` | `en/use-dify/model-providers/` |
+| graphon | `src/graphon/graph_engine/`, `src/graphon/runtime/` | workflow engine behavior, execution semantics |
+
+When checking dify PRs, also scan recent merges in `langgenius/graphon` for the same release window. A user-visible workflow change may ship as a graphon release plus a dify pin bump (look for changes to `api/pyproject.toml` and `api/uv.lock`).
 
 **Important**: These mappings are heuristic. For every candidate match:
 

@@ -15,7 +15,7 @@ For task-specific guidance, see `writing-guides/index.md`.
 - Write in English only, except when specifically optimizing Chinese or Japanese translations.
 - Only edit the English section in `docs.json`. Translation sections sync automatically.
 - MDX files require `title` and `description` in YAML frontmatter.
-- When writing about a feature, verify behavior against the Dify codebase, not just existing docs. Existing docs may be outdated or completely wrong. When rewriting a page, treat every claim in the original as unverified. Check field names, types, required/optional status, and behavior descriptions against the current code. Never carry forward details from legacy docs without independent verification.
+- When writing about a feature, verify behavior against the Dify codebase, not just existing docs. Existing docs may be outdated or completely wrong. When rewriting a page, treat every claim in the original as unverified. Check field names, types, required/optional status, and behavior descriptions against the current code. Never carry forward details from legacy docs without independent verification. The backend is split across two repos: built-in workflow nodes, the graph engine, runtime, and model_runtime live in the `graphon` repo (version-pinned in `dify/api/pyproject.toml`); integration nodes (Agent, Knowledge, Datasource, Trigger), orchestration, RAG, and tools stay in `dify`. Verify against the graphon version actually pinned by dify, not graphon `main`.
 - For new features, the user may specify a development branch. Code on development branches may be in flux—when behavior is ambiguous, ask rather than assume.
 - When adding or updating internal-only instructions, tooling, configs, or other non-public files, ensure all paths that should not be exposed by Mintlify are covered in `.mintignore`.
 - Never use `--no-verify` when committing.