{"owner":"arc53","repo":"DocsGPT","hasSkills":true,"hasMcp":true,"mcpConfig":{"mcpServers":{"DocsGPT":{"command":"npx","args":["-y","@modelcontextprotocol/server-DocsGPT"]}}},"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\n- Read `CONTRIBUTING.md` before making non-trivial changes.\n- For day-to-day development and feature work, follow the development-environment workflow rather than defaulting to `setup.sh` / `setup.ps1`.\n- Avoid using the setup scripts during normal feature work unless the user explicitly asks for them. Users configure `.env` usually.\n- Try to follow red/green TDD\n\n### Check existing dev prerequisites first\n\nFor feature work, do **not** assume the environment needs to be recreated.\n\n- Check whether the user already has a Python virtual environment such as `venv/` or `.venv/`.\n- Check whether Postgres is already running and reachable via `POSTGRES_URI` (the canonical user-data store).\n- Check whether Redis is already running.\n- Reuse what is already working. Do not stop or recreate Postgres, Redis, or the Python environment unless the task is environment setup or troubleshooting.\n\n> MongoDB is **not** required for the default install. It is only needed if\n> the user opts into the Mongo vector-store backend (`VECTOR_STORE=mongodb`)\n> or is running the one-shot `scripts/db/backfill.py` to migrate existing\n> user data from the legacy Mongo-based install. In those cases, `pymongo`\n> is available as an optional extra, not a core dependency.\n\n## Normal local development commands\n\nUse these commands once the dev prerequisites above are satisfied.\n\n### Backend\n\n```bash\nsource .venv/bin/activate  # macOS/Linux\nuv pip install -r application/requirements.txt  # or: pip install -r application/requirements.txt\n```\n\nRun the API. For local dev, prefer the ASGI entrypoint under uvicorn — it\nserves the **whole** app, matches production, and hot-reloads:\n\n```bash\nuvicorn application.asgi:asgi_app --host 0.0.0.0 --port 7091 --reload\n```\n\n`flask --app application/app.py run --host=0.0.0.0 --port=7091` is a faster\ninner loop (quick startup, the Werkzeug interactive debugger), but it serves\n**only** the WSGI Flask app and omits the routes mounted on the ASGI shell\nin `application/asgi.py`:\n\n- the `/mcp` FastMCP endpoint, and\n- the native-async SSE reconnect reader `GET /api/messages/<id>/events`.\n\nUnder `flask run` those paths 404. Chat still works (`POST /stream` is a\nFlask route), but a stream interrupted by a disconnect won't auto-resume on\nreconnect. Use `flask run` only when you don't need those routes.\n\nProduction uses `gunicorn -k uvicorn_worker.UvicornWorker` against the same\n`application.asgi:asgi_app` target; see `application/Dockerfile` for the\nfull flag set.\n\nRun the Celery worker in a separate terminal (if needed):\n\n```bash\ncelery -A application.app.celery worker -l INFO\n```\n\nOn macOS, prefer the solo pool for Celery:\n\n```bash\npython -m celery -A application.app.celery worker -l INFO --pool=solo\n```\n\nA bare worker (no `-Q`) consumes every configured queue, so one worker does the\nwhole job — app tasks and document parsing (the `read_document` tool / workflow\nnative-file parse) alike. Use `-Q` only to split load: run the main worker with\n`-Q docsgpt` and a dedicated (e.g. GPU-enabled) parser worker with `-Q parsing`\nfor heavy OCR.\n\n### Frontend\n\nInstall dependencies only when needed, then run the dev server:\n\n```bash\ncd frontend\nnpm install --include=dev\nnpm run dev\n```\n\n### Docs site\n\n```bash\ncd docs\nnpm install\n```\n\n### Python / backend changes validation\n\n```bash\nruff check .\npython -m pytest\n```\n\n### Frontend changes\n\n```bash\ncd frontend && npm run lint\ncd frontend && npm run build\n```\n\n### Documentation changes\n\n```bash\ncd docs && npm run build\n```\n\nIf Vale is installed locally and you edited prose, also run:\n\n```bash\nvale .\n```\n\n## Repository map\n\n- `application/`: Flask backend, API routes, agent logic, retrieval, parsing, security, storage, Celery worker, and WSGI entrypoints.\n- `tests/`: backend unit/integration tests and test-only Python dependencies.\n- `frontend/`: Vite + React + TypeScript application.\n- `frontend/src/`: main UI code, including `components`, `conversation`, `hooks`, `locale`, `settings`, `upload`, and Redux store wiring in `store.ts`.\n- `docs/`: separate documentation site built with Next.js/Nextra.\n- `extensions/`: integrations and widgets — currently the Chatwoot webhook bridge and the React widget (published to npm as `docsgpt`). The Discord bot, Slack bot, and Chrome extension have been moved to their own repos under `arc53/`.\n- `deployment/`: Docker Compose variants and Kubernetes manifests.\n\n## Coding rules\n\n### Backend\n\n- Follow PEP 8 and keep Python line length at or under 120 characters.\n- Use type hints for function arguments and return values.\n- Add Google-style docstrings to new or substantially changed functions and classes.\n- Add or update tests under `tests/` for backend behavior changes.\n- Keep changes narrow in `api`, `auth`, `security`, `parser`, `retriever`, and `storage` areas.\n\n### Backend Abstractions\n\n- LLM providers implement a common interface in `application/llm/` (add new providers by extending the base class).\n- Vector stores are abstracted in `application/vectorstore/`.\n- Parsers live in `application/parser/` and handle different document formats in the ingestion stage.\n- Agents and tools are in `application/agents/` and `application/agents/tools/`.\n- Celery setup/config lives in `application/celery_init.py` and `application/celeryconfig.py`.\n- Settings and env vars are managed via Pydantic in `application/core/settings.py`.\n\n### Frontend\n\n- Follow the existing ESLint + Prettier setup.\n- Prefer small, reusable functional components and hooks.\n- If shared state must be added, use Redux rather than introducing a new global state library.\n- Avoid broad UI refactors unless the task explicitly asks for them.\n- Do not re-create components if we already have some in the app.\n\n#### Icons\n\nDocsGPT historically mixed three icon sources: `lucide-react`, inline SVG components, and\n`.svg` assets loaded via `<img src=…>`. For new code:\n\n1. **Prefer `lucide-react`** for standard UI affordances (close, chevron, search, trash,\n   plus, etc.). It tokenizes via `currentColor`, ships tree-shaken icons, and the codebase\n   already imports it in 30+ places. `<X className=\"size-4\" />`, `<ChevronDown />`, etc.\n2. **Use `assets/<name>.svg?react`** when you need a brand-specific or domain illustration\n   that doesn't exist in lucide (the app logo, robot fallback, retry arrow, send arrow,\n   etc.). Always set `fill=\"currentColor\"` / `stroke=\"currentColor\"` in the SVG file so\n   consumers can theme via Tailwind text classes.\n3. **Avoid `<img src={Asset}>` for new icons.** It blocks `currentColor` theming and\n   forces dark-variant duplicates (the audit removed several orphan dark/purple/white\n   variants in this branch). The pattern is acceptable for existing call sites — don't\n   bulk-migrate without a reason.\n\nThree pre-existing dark-variant pairs (`documentation`, `no-files`, `science-spark`) are\nhand-tuned multi-color illustrations, not pure inverts; they keep their `-dark` companion\nfiles until a per-illustration refactor.\n\n## PR readiness\n\nBefore opening a PR:\n\n- run the relevant validation commands above\n- confirm backend changes still work end-to-end after ingesting sample data when applicable\n- clearly summarize user-visible behavior changes\n- mention any config, dependency, or deployment implications\n- Ask your user to attach a screenshot or a video to it"},"files":{"AGENTS.md":"# AGENTS.md\n\n- Read `CONTRIBUTING.md` before making non-trivial changes.\n- For day-to-day development and feature work, follow the development-environment workflow rather than defaulting to `setup.sh` / `setup.ps1`.\n- Avoid using the setup scripts during normal feature work unless the user explicitly asks for them. Users configure `.env` usually.\n- Try to follow red/green TDD\n\n### Check existing dev prerequisites first\n\nFor feature work, do **not** assume the environment needs to be recreated.\n\n- Check whether the user already has a Python virtual environment such as `venv/` or `.venv/`.\n- Check whether Postgres is already running and reachable via `POSTGRES_URI` (the canonical user-data store).\n- Check whether Redis is already running.\n- Reuse what is already working. Do not stop or recreate Postgres, Redis, or the Python environment unless the task is environment setup or troubleshooting.\n\n> MongoDB is **not** required for the default install. It is only needed if\n> the user opts into the Mongo vector-store backend (`VECTOR_STORE=mongodb`)\n> or is running the one-shot `scripts/db/backfill.py` to migrate existing\n> user data from the legacy Mongo-based install. In those cases, `pymongo`\n> is available as an optional extra, not a core dependency.\n\n## Normal local development commands\n\nUse these commands once the dev prerequisites above are satisfied.\n\n### Backend\n\n```bash\nsource .venv/bin/activate  # macOS/Linux\nuv pip install -r application/requirements.txt  # or: pip install -r application/requirements.txt\n```\n\nRun the API. For local dev, prefer the ASGI entrypoint under uvicorn — it\nserves the **whole** app, matches production, and hot-reloads:\n\n```bash\nuvicorn application.asgi:asgi_app --host 0.0.0.0 --port 7091 --reload\n```\n\n`flask --app application/app.py run --host=0.0.0.0 --port=7091` is a faster\ninner loop (quick startup, the Werkzeug interactive debugger), but it serves\n**only** the WSGI Flask app and omits the routes mounted on the ASGI shell\nin `application/asgi.py`:\n\n- the `/mcp` FastMCP endpoint, and\n- the native-async SSE reconnect reader `GET /api/messages/<id>/events`.\n\nUnder `flask run` those paths 404. Chat still works (`POST /stream` is a\nFlask route), but a stream interrupted by a disconnect won't auto-resume on\nreconnect. Use `flask run` only when you don't need those routes.\n\nProduction uses `gunicorn -k uvicorn_worker.UvicornWorker` against the same\n`application.asgi:asgi_app` target; see `application/Dockerfile` for the\nfull flag set.\n\nRun the Celery worker in a separate terminal (if needed):\n\n```bash\ncelery -A application.app.celery worker -l INFO\n```\n\nOn macOS, prefer the solo pool for Celery:\n\n```bash\npython -m celery -A application.app.celery worker -l INFO --pool=solo\n```\n\nA bare worker (no `-Q`) consumes every configured queue, so one worker does the\nwhole job — app tasks and document parsing (the `read_document` tool / workflow\nnative-file parse) alike. Use `-Q` only to split load: run the main worker with\n`-Q docsgpt` and a dedicated (e.g. GPU-enabled) parser worker with `-Q parsing`\nfor heavy OCR.\n\n### Frontend\n\nInstall dependencies only when needed, then run the dev server:\n\n```bash\ncd frontend\nnpm install --include=dev\nnpm run dev\n```\n\n### Docs site\n\n```bash\ncd docs\nnpm install\n```\n\n### Python / backend changes validation\n\n```bash\nruff check .\npython -m pytest\n```\n\n### Frontend changes\n\n```bash\ncd frontend && npm run lint\ncd frontend && npm run build\n```\n\n### Documentation changes\n\n```bash\ncd docs && npm run build\n```\n\nIf Vale is installed locally and you edited prose, also run:\n\n```bash\nvale .\n```\n\n## Repository map\n\n- `application/`: Flask backend, API routes, agent logic, retrieval, parsing, security, storage, Celery worker, and WSGI entrypoints.\n- `tests/`: backend unit/integration tests and test-only Python dependencies.\n- `frontend/`: Vite + React + TypeScript application.\n- `frontend/src/`: main UI code, including `components`, `conversation`, `hooks`, `locale`, `settings`, `upload`, and Redux store wiring in `store.ts`.\n- `docs/`: separate documentation site built with Next.js/Nextra.\n- `extensions/`: integrations and widgets — currently the Chatwoot webhook bridge and the React widget (published to npm as `docsgpt`). The Discord bot, Slack bot, and Chrome extension have been moved to their own repos under `arc53/`.\n- `deployment/`: Docker Compose variants and Kubernetes manifests.\n\n## Coding rules\n\n### Backend\n\n- Follow PEP 8 and keep Python line length at or under 120 characters.\n- Use type hints for function arguments and return values.\n- Add Google-style docstrings to new or substantially changed functions and classes.\n- Add or update tests under `tests/` for backend behavior changes.\n- Keep changes narrow in `api`, `auth`, `security`, `parser`, `retriever`, and `storage` areas.\n\n### Backend Abstractions\n\n- LLM providers implement a common interface in `application/llm/` (add new providers by extending the base class).\n- Vector stores are abstracted in `application/vectorstore/`.\n- Parsers live in `application/parser/` and handle different document formats in the ingestion stage.\n- Agents and tools are in `application/agents/` and `application/agents/tools/`.\n- Celery setup/config lives in `application/celery_init.py` and `application/celeryconfig.py`.\n- Settings and env vars are managed via Pydantic in `application/core/settings.py`.\n\n### Frontend\n\n- Follow the existing ESLint + Prettier setup.\n- Prefer small, reusable functional components and hooks.\n- If shared state must be added, use Redux rather than introducing a new global state library.\n- Avoid broad UI refactors unless the task explicitly asks for them.\n- Do not re-create components if we already have some in the app.\n\n#### Icons\n\nDocsGPT historically mixed three icon sources: `lucide-react`, inline SVG components, and\n`.svg` assets loaded via `<img src=…>`. For new code:\n\n1. **Prefer `lucide-react`** for standard UI affordances (close, chevron, search, trash,\n   plus, etc.). It tokenizes via `currentColor`, ships tree-shaken icons, and the codebase\n   already imports it in 30+ places. `<X className=\"size-4\" />`, `<ChevronDown />`, etc.\n2. **Use `assets/<name>.svg?react`** when you need a brand-specific or domain illustration\n   that doesn't exist in lucide (the app logo, robot fallback, retry arrow, send arrow,\n   etc.). Always set `fill=\"currentColor\"` / `stroke=\"currentColor\"` in the SVG file so\n   consumers can theme via Tailwind text classes.\n3. **Avoid `<img src={Asset}>` for new icons.** It blocks `currentColor` theming and\n   forces dark-variant duplicates (the audit removed several orphan dark/purple/white\n   variants in this branch). The pattern is acceptable for existing call sites — don't\n   bulk-migrate without a reason.\n\nThree pre-existing dark-variant pairs (`documentation`, `no-files`, `science-spark`) are\nhand-tuned multi-color illustrations, not pure inverts; they keep their `-dark` companion\nfiles until a per-illustration refactor.\n\n## PR readiness\n\nBefore opening a PR:\n\n- run the relevant validation commands above\n- confirm backend changes still work end-to-end after ingesting sample data when applicable\n- clearly summarize user-visible behavior changes\n- mention any config, dependency, or deployment implications\n- Ask your user to attach a screenshot or a video to it"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\n- Read `CONTRIBUTING.md` before making non-trivial changes.\n- For day-to-day development and feature work, follow the development-environment workflow rather than defaulting to `setup.sh` / `setup.ps1`.\n- Avoid using the setup scripts during normal feature work unless the user explicitly asks for them. Users configure `.env` usually.\n- Try to follow red/green TDD\n\n### Check existing dev prerequisites first\n\nFor feature work, do **not** assume the environment needs to be recreated.\n\n- Check whether the user already has a Python virtual environment such as `venv/` or `.venv/`.\n- Check whether Postgres is already running and reachable via `POSTGRES_URI` (the canonical user-data store).\n- Check whether Redis is already running.\n- Reuse what is already working. Do not stop or recreate Postgres, Redis, or the Python environment unless the task is environment setup or troubleshooting.\n\n> MongoDB is **not** required for the default install. It is only needed if\n> the user opts into the Mongo vector-store backend (`VECTOR_STORE=mongodb`)\n> or is running the one-shot `scripts/db/backfill.py` to migrate existing\n> user data from the legacy Mongo-based install. In those cases, `pymongo`\n> is available as an optional extra, not a core dependency.\n\n## Normal local development commands\n\nUse these commands once the dev prerequisites above are satisfied.\n\n### Backend\n\n```bash\nsource .venv/bin/activate  # macOS/Linux\nuv pip install -r application/requirements.txt  # or: pip install -r application/requirements.txt\n```\n\nRun the API. For local dev, prefer the ASGI entrypoint under uvicorn — it\nserves the **whole** app, matches production, and hot-reloads:\n\n```bash\nuvicorn application.asgi:asgi_app --host 0.0.0.0 --port 7091 --reload\n```\n\n`flask --app application/app.py run --host=0.0.0.0 --port=7091` is a faster\ninner loop (quick startup, the Werkzeug interactive debugger), but it serves\n**only** the WSGI Flask app and omits the routes mounted on the ASGI shell\nin `application/asgi.py`:\n\n- the `/mcp` FastMCP endpoint, and\n- the native-async SSE reconnect reader `GET /api/messages/<id>/events`.\n\nUnder `flask run` those paths 404. Chat still works (`POST /stream` is a\nFlask route), but a stream interrupted by a disconnect won't auto-resume on\nreconnect. Use `flask run` only when you don't need those routes.\n\nProduction uses `gunicorn -k uvicorn_worker.UvicornWorker` against the same\n`application.asgi:asgi_app` target; see `application/Dockerfile` for the\nfull flag set.\n\nRun the Celery worker in a separate terminal (if needed):\n\n```bash\ncelery -A application.app.celery worker -l INFO\n```\n\nOn macOS, prefer the solo pool for Celery:\n\n```bash\npython -m celery -A application.app.celery worker -l INFO --pool=solo\n```\n\nA bare worker (no `-Q`) consumes every configured queue, so one worker does the\nwhole job — app tasks and document parsing (the `read_document` tool / workflow\nnative-file parse) alike. Use `-Q` only to split load: run the main worker with\n`-Q docsgpt` and a dedicated (e.g. GPU-enabled) parser worker with `-Q parsing`\nfor heavy OCR.\n\n### Frontend\n\nInstall dependencies only when needed, then run the dev server:\n\n```bash\ncd frontend\nnpm install --include=dev\nnpm run dev\n```\n\n### Docs site\n\n```bash\ncd docs\nnpm install\n```\n\n### Python / backend changes validation\n\n```bash\nruff check .\npython -m pytest\n```\n\n### Frontend changes\n\n```bash\ncd frontend && npm run lint\ncd frontend && npm run build\n```\n\n### Documentation changes\n\n```bash\ncd docs && npm run build\n```\n\nIf Vale is installed locally and you edited prose, also run:\n\n```bash\nvale .\n```\n\n## Repository map\n\n- `application/`: Flask backend, API routes, agent logic, retrieval, parsing, security, storage, Celery worker, and WSGI entrypoints.\n- `tests/`: backend unit/integration tests and test-only Python dependencies.\n- `frontend/`: Vite + React + TypeScript application.\n- `frontend/src/`: main UI code, including `components`, `conversation`, `hooks`, `locale`, `settings`, `upload`, and Redux store wiring in `store.ts`.\n- `docs/`: separate documentation site built with Next.js/Nextra.\n- `extensions/`: integrations and widgets — currently the Chatwoot webhook bridge and the React widget (published to npm as `docsgpt`). The Discord bot, Slack bot, and Chrome extension have been moved to their own repos under `arc53/`.\n- `deployment/`: Docker Compose variants and Kubernetes manifests.\n\n## Coding rules\n\n### Backend\n\n- Follow PEP 8 and keep Python line length at or under 120 characters.\n- Use type hints for function arguments and return values.\n- Add Google-style docstrings to new or substantially changed functions and classes.\n- Add or update tests under `tests/` for backend behavior changes.\n- Keep changes narrow in `api`, `auth`, `security`, `parser`, `retriever`, and `storage` areas.\n\n### Backend Abstractions\n\n- LLM providers implement a common interface in `application/llm/` (add new providers by extending the base class).\n- Vector stores are abstracted in `application/vectorstore/`.\n- Parsers live in `application/parser/` and handle different document formats in the ingestion stage.\n- Agents and tools are in `application/agents/` and `application/agents/tools/`.\n- Celery setup/config lives in `application/celery_init.py` and `application/celeryconfig.py`.\n- Settings and env vars are managed via Pydantic in `application/core/settings.py`.\n\n### Frontend\n\n- Follow the existing ESLint + Prettier setup.\n- Prefer small, reusable functional components and hooks.\n- If shared state must be added, use Redux rather than introducing a new global state library.\n- Avoid broad UI refactors unless the task explicitly asks for them.\n- Do not re-create components if we already have some in the app.\n\n#### Icons\n\nDocsGPT historically mixed three icon sources: `lucide-react`, inline SVG components, and\n`.svg` assets loaded via `<img src=…>`. For new code:\n\n1. **Prefer `lucide-react`** for standard UI affordances (close, chevron, search, trash,\n   plus, etc.). It tokenizes via `currentColor`, ships tree-shaken icons, and the codebase\n   already imports it in 30+ places. `<X className=\"size-4\" />`, `<ChevronDown />`, etc.\n2. **Use `assets/<name>.svg?react`** when you need a brand-specific or domain illustration\n   that doesn't exist in lucide (the app logo, robot fallback, retry arrow, send arrow,\n   etc.). Always set `fill=\"currentColor\"` / `stroke=\"currentColor\"` in the SVG file so\n   consumers can theme via Tailwind text classes.\n3. **Avoid `<img src={Asset}>` for new icons.** It blocks `currentColor` theming and\n   forces dark-variant duplicates (the audit removed several orphan dark/purple/white\n   variants in this branch). The pattern is acceptable for existing call sites — don't\n   bulk-migrate without a reason.\n\nThree pre-existing dark-variant pairs (`documentation`, `no-files`, `science-spark`) are\nhand-tuned multi-color illustrations, not pure inverts; they keep their `-dark` companion\nfiles until a per-illustration refactor.\n\n## PR readiness\n\nBefore opening a PR:\n\n- run the relevant validation commands above\n- confirm backend changes still work end-to-end after ingesting sample data when applicable\n- clearly summarize user-visible behavior changes\n- mention any config, dependency, or deployment implications\n- Ask your user to attach a screenshot or a video to it","category":"root","tokens":1834}]}