Spaces:
Configuration error
Configuration error
File size: 4,222 Bytes
55086fb |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 |
# Contributing to Verifacts Backend
Welcome to the Verifacts engineering team! This guide will help you set up your development environment and understand our engineering standards.
## π Environment Setup
We use **Poetry** for dependency management to ensure deterministic builds across all micro-modules.
### 1. Installation
```bash
# Install Project Dependencies
poetry install
````
### 2\. Configuration
Copy the example environment file:
```bash
cp .env.example .env
```
**Required Variables:**
* `OPENAI_API_KEY`: For LLM extraction.
* `FIRECRAWL_API_KEY`: For web scraping.
* `GOOGLE_FACT_CHECK_KEY`: For verification.
### 3\. Running the Server
Start the hot-reloading development server:
```bash
poetry run uvicorn app.api.server:app --reload
```
-----
## π³ Git Workflow & Branching Strategy
We follow a strict branching model to keep our codebase stable. **Never push directly to `main`.**
### Branch Naming Convention
* **Features:** `feat/short-description` (e.g., `feat/add-sentiment-node`)
* **Bug Fixes:** `fix/short-description` (e.g., `fix/firecrawl-timeout`)
* **Documentation:** `docs/short-description` (e.g., `docs/update-api-schema`)
* **Chore/Refactor:** `chore/short-description` (e.g., `chore/bump-poetry-version`)
### The Workflow
1. **Sync with Main:**
```bash
git checkout main
git pull origin main
```
2. **Create Branch:**
```bash
git checkout -b feat/my-new-feature
```
3. **Code & Test:** Write your code and ensure `poetry run pytest` passes.
4. **Push & PR:** Push your branch and open a Pull Request (PR) for review.
-----
## π Commit Message Standards
We use **Conventional Commits** to automate our changelogs. Your commit message must look like this:
`<type>(<scope>): <short summary>`
### Types
* `feat`: A new feature (e.g., adding a new LangGraph node).
* `fix`: A bug fix.
* `docs`: Documentation only changes.
* `style`: Formatting, missing semi-colons, etc. (no code change).
* `refactor`: A code change that neither fixes a bug nor adds a feature.
* `perf`: A code change that improves performance.
* `test`: Adding missing tests.
* `chore`: Maintainance tasks (e.g., updating `.gitignore`).
### Examples
* β
`feat(graph): add sentiment analysis node to workflow`
* β
`fix(api): handle 404 error from Firecrawl`
* β
`docs(readme): update setup instructions for Windows`
* β `Fixed the bug` (Too vague)
* β `Added new agent` (Missing scope)
-----
## π οΈ How to Add a New Feature (The "Node" Workflow)
Adding intelligence to Veritas means adding a **Node** to the LangGraph. Follow this 4-step process:
### Step 1: Create the Logic (The Module)
Create a new file in `app/graph/nodes/`. It must accept `AgentState` and return a dictionary of updates.
* *File:* `app/graph/nodes/sentiment.py`
* *Function:* `async def sentiment_node(state: AgentState) -> Dict[str, Any]: ...`
### Step 2: Update the State
If your node produces new data (e.g., a "sentiment score"), define it in the shared state.
* *File:* `app/graph/state.py`
* *Action:* Add `sentiment_score: float` to the `AgentState` TypedDict.
### Step 3: Register in the Graph
Wire your new node into the orchestration flow.
* *File:* `app/graph/workflow.py`
* *Action:*
1. `workflow.add_node("sentiment", sentiment_node)`
2. Define when it runs (e.g., `workflow.add_edge("reader", "sentiment")`).
### Step 4: Expose via API (Optional)
If the frontend needs to see this data, update the response model.
* *File:* `app/api/v1/models.py` (or `server.py`)
* *Action:* Add the field to the Pydantic Response model.
-----
## π§ͺ Testing Requirements
Before submitting a PR, ensure you have added tests for your new node.
```bash
# Run unit tests
poetry run pytest
# Run linting manually (Recommended)
poetry run ruff check .
```
## Pull Request Reviews
All PRs must be reviewed by at least one other team member. Look for:
* Code quality and adherence to standards.
* Proper testing coverage.
* Clear and descriptive commit messages.
Thank you for contributing to Verifacts! Your efforts help us build a reliable and intelligent verification platform. |