Spaces:
Sleeping
Sleeping
Commit Β·
5744898
1
Parent(s): 17b6c66
updated file_agent execute condition
Browse files- README_CoderG_05182026.md +171 -43
- core_logic.py +37 -27
- perception_agent.py +2 -2
README_CoderG_05182026.md
CHANGED
|
@@ -33,61 +33,68 @@ A production-ready orchestration workflow tool that cuts code asset production t
|
|
| 33 |
* **Infrastructure Layer:** `GitHub REST API v3 Engine` β Automates remote cloud platform discovery, profile querying, and repository initialization on headless systems.
|
| 34 |
* **Format Compilation Compilers:** `PyYAML`, `TOML`, `python-docx` β Decodes plaintext generator responses directly into precise configuration scripts and professional document layouts.
|
| 35 |
|
| 36 |
-
---
|
| 37 |
-
|
| 38 |
-
|
| 39 |
---
|
| 40 |
|
| 41 |
## ποΈ Core Architecture Overview
|
| 42 |
|
| 43 |
CoderG bypasses monolithic script patterns by delegating tasks across highly specialized micro-agents:
|
| 44 |
|
| 45 |
-
|
| 46 |
-
|
| 47 |
-
|
| 48 |
-
|
| 49 |
-
|
| 50 |
-
|
| 51 |
-
|
| 52 |
-
|
| 53 |
-
|
| 54 |
-
|
| 55 |
-
|
| 56 |
-
|
| 57 |
-
|
| 58 |
-
|
| 59 |
-
|
| 60 |
-
|
|
|
|
|
|
|
|
|
|
|
|
|
| 61 |
|
|
|
|
| 62 |
|
| 63 |
## π System Flowchart & Interaction Model
|
| 64 |
|
| 65 |
The architectural diagram below traces an instruction's path as it travels through CoderG's isolated processing channels:
|
| 66 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 67 |
|
| 68 |
-
|
| 69 |
-
β
|
| 70 |
-
βΌ
|
| 71 |
-
ββββββββββββ Streams Text Tokens
|
| 72 |
-
β app.py β <ββββββββββββββββββββββββββββββββ
|
| 73 |
-
ββββββ¬ββββββ β
|
| 74 |
-
β Invokes Event Processing β
|
| 75 |
-
βΌ β
|
| 76 |
-
ββββββββββββββββ Passes Raw Artifacts ββββββββββββββββ
|
| 77 |
-
βcore_logic.py β βββββββββββββββββββββ> βfile_agent.py β
|
| 78 |
-
ββββββββββββββββ ββββββββ¬ββββββββ
|
| 79 |
-
β Writes Workspace Files
|
| 80 |
-
βΌ
|
| 81 |
-
ββββββββββββββββ Executes Remote Push ββββββββββββββββ
|
| 82 |
-
βgit_agent.py β <βββββββββββββββββββββ β outputs/ β βββ [Creates Backups]
|
| 83 |
-
ββββββββ¬ββββββββ via Control Tower ββββββββββββββββ
|
| 84 |
-
β
|
| 85 |
-
βββΊ [API Provision check] βββΊ Pushes Assets to Remote GitHub Target
|
| 86 |
-
βΌ
|
| 87 |
-
ββββββββββββββββ
|
| 88 |
-
β temp_repo/ β βββΊ Purges Folder Completely on Termination (Zero Footprint)
|
| 89 |
-
ββββββββββββββββ
|
| 90 |
-
|
| 91 |
|
| 92 |
### Module Component Breakdown/Descriptions
|
| 93 |
1. **`app.py` (Control Tower / UI Layer):** A 3-column asymmetric Gradio interface managing dynamic conversation sessions, asynchronous text streaming execution, state tracking, and explicit telemetry log piping.
|
|
@@ -120,12 +127,73 @@ The architectural diagram below traces an instruction's path as it travels throu
|
|
| 120 |
* **Core Logic:** A file utility tracking internal state changes.
|
| 121 |
* **Key Mechanisms:** Appends structured, timestamped logs out to `outputs/agent.log` to track initialization tasks, file events, or deployment problems.
|
| 122 |
|
| 123 |
-
|
|
|
|
|
|
|
| 124 |
|
| 125 |
* agent_logging.py,
|
| 126 |
* file_agent.py,
|
| 127 |
* git_agent.py
|
| 128 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 129 |
---
|
| 130 |
|
| 131 |
## π οΈ Tech-Stack & Framework Layering
|
|
@@ -156,6 +224,66 @@ To keep internal host resources, containers, or Hugging Face spaces lean and unb
|
|
| 156 |
|
| 157 |
---
|
| 158 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 159 |
## π Planned & Strategic Enhancements
|
| 160 |
|
| 161 |
### Phase 1: Context Capture Optimizations
|
|
|
|
| 33 |
* **Infrastructure Layer:** `GitHub REST API v3 Engine` β Automates remote cloud platform discovery, profile querying, and repository initialization on headless systems.
|
| 34 |
* **Format Compilation Compilers:** `PyYAML`, `TOML`, `python-docx` β Decodes plaintext generator responses directly into precise configuration scripts and professional document layouts.
|
| 35 |
|
|
|
|
|
|
|
|
|
|
| 36 |
---
|
| 37 |
|
| 38 |
## ποΈ Core Architecture Overview
|
| 39 |
|
| 40 |
CoderG bypasses monolithic script patterns by delegating tasks across highly specialized micro-agents:
|
| 41 |
|
| 42 |
+
> The blueprint maps out the decoupled Manager-Worker design pattern, illustrating presentation layer's controlling specialized modules while piping structural logs to an audit trail
|
| 43 |
+
|
| 44 |
+
+---------------------------------------+
|
| 45 |
+
| app.py (Manager) | <--- Gradio Presentation Control
|
| 46 |
+
+---------------------------------------+
|
| 47 |
+
|
|
| 48 |
+
+------------------------+------------------------+
|
| 49 |
+
| | |
|
| 50 |
+
v v v
|
| 51 |
+
+-----------------------++-----------------------++-----------------------+
|
| 52 |
+
| core_logic.py || file_agent.py || git_agent.py |
|
| 53 |
+
| (The Brain) || (The Writer) || (The Courier) |
|
| 54 |
+
+-----------------------++-----------------------++-----------------------+
|
| 55 |
+
| | |
|
| 56 |
+
+------------------------+------------------------+
|
| 57 |
+
|
|
| 58 |
+
v
|
| 59 |
+
+---------------------------------------+
|
| 60 |
+
| agent_logging.py (Audit) | ---> outputs/agent.log
|
| 61 |
+
+---------------------------------------+
|
| 62 |
|
| 63 |
+
---
|
| 64 |
|
| 65 |
## π System Flowchart & Interaction Model
|
| 66 |
|
| 67 |
The architectural diagram below traces an instruction's path as it travels through CoderG's isolated processing channels:
|
| 68 |
|
| 69 |
+
> The flowchart tracks the - Run-time Execution Flow - exact lifecycle of a user request, tracing token streaming, workspace generation, remote repository initialization, and the final zero-footprint directory purge.
|
| 70 |
+
|
| 71 |
+
[ User Input ]
|
| 72 |
+
|
|
| 73 |
+
v
|
| 74 |
+
+------------+ Streams Text Tokens
|
| 75 |
+
| app.py | <-------------------------------------------------------+
|
| 76 |
+
+------------+ |
|
| 77 |
+
| |
|
| 78 |
+
| Invokes Event Processing |
|
| 79 |
+
v |
|
| 80 |
+
+------------+ Passes Raw Artifacts +---------------+ |
|
| 81 |
+
| core_logic | ---------------------------------> | file_agent | ---+
|
| 82 |
+
+------------+ +---------------+
|
| 83 |
+
| |
|
| 84 |
+
| Writes Workspace Files | Creates Backups
|
| 85 |
+
v v
|
| 86 |
+
+------------+ Executes Remote Push +---------------+
|
| 87 |
+
| git_agent | <--------------------------------- | outputs/ |
|
| 88 |
+
+------------+ via Control Tower +---------------+
|
| 89 |
+
|
|
| 90 |
+
+---> [ API Provision Check ] ---> Pushes Assets to Remote GitHub Target
|
| 91 |
+
|
|
| 92 |
+
v
|
| 93 |
+
+------------+
|
| 94 |
+
| temp_repo/ | ---> Purges Folder Completely on Termination (Zero Footprint)
|
| 95 |
+
+------------+
|
| 96 |
|
| 97 |
+
---
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 98 |
|
| 99 |
### Module Component Breakdown/Descriptions
|
| 100 |
1. **`app.py` (Control Tower / UI Layer):** A 3-column asymmetric Gradio interface managing dynamic conversation sessions, asynchronous text streaming execution, state tracking, and explicit telemetry log piping.
|
|
|
|
| 127 |
* **Core Logic:** A file utility tracking internal state changes.
|
| 128 |
* **Key Mechanisms:** Appends structured, timestamped logs out to `outputs/agent.log` to track initialization tasks, file events, or deployment problems.
|
| 129 |
|
| 130 |
+
---
|
| 131 |
+
|
| 132 |
+
### Worker Module - Detailed Analysis:
|
| 133 |
|
| 134 |
* agent_logging.py,
|
| 135 |
* file_agent.py,
|
| 136 |
* git_agent.py
|
| 137 |
|
| 138 |
+
|
| 139 |
+
The application relies on an isolated Manager-Worker pattern.
|
| 140 |
+
|
| 141 |
+
**app.py** sets up the interface,
|
| 142 |
+
**core_logic.py** makes strategic architectural decisions, and
|
| 143 |
+
the **Worker Module (agent_logging.py, file_agent.py, git_agent.py)** executes the concrete file system and network operations.
|
| 144 |
+
|
| 145 |
+
Here is exactly how each worker behaves, executes tasks, and intersects with the application core:
|
| 146 |
+
|
| 147 |
+
1. agent_logging.py (The Audit Trail)
|
| 148 |
+
|
| 149 |
+
**Core Function:** This script provides unified telemetry and observability for the entire application. It handles raw I/O operations to append formatted structural logs into outputs/agent.log with high-precision timestamps (%Y-%m-%d %H:%M:%S).
|
| 150 |
+
|
| 151 |
+
**Relation to app.py & core_logic.py:** It acts as a passive background layer. Rather than interacting with the user interface, it listens to the other agents. Whenever core_logic.py hits an inference issue or a worker finishes a physical action, they call log_agent_action() to register the event.
|
| 152 |
+
|
| 153 |
+
**Detailed Operation:**
|
| 154 |
+
|
| 155 |
+
* Accepts an action_type (e.g., FILE_CREATION, GIT_ERROR) and a detailed message string.
|
| 156 |
+
* Proactively checks if the outputs folder exists; if missing, it runs an on-the-fly directory creation.
|
| 157 |
+
*3.* Opens the log file in append mode ("a"), writing the log payload in an explicit format: [TIMESTAMP] [ACTION] Message.
|
| 158 |
+
|
| 159 |
+
2. file_agent.py (The Document Writer)
|
| 160 |
+
|
| 161 |
+
**Core Function:** This is your disk serialization worker. It takes raw text tokens or structural payloads generated by your LLM core and turns them into actual physical workspace formats on disk (.md, .txt, .yaml, .toml, .docx).
|
| 162 |
+
|
| 163 |
+
**Relation to app.py & core_logic.py:** Once core_logic.py finishes streaming its raw textual architectural insights back to app.py for user presentation, it immediately calls file_agent.write_document(). This saves the generated material locally before any remote actions take place.
|
| 164 |
+
|
| 165 |
+
**Detailed Operation:**
|
| 166 |
+
|
| 167 |
+
* Inspects the file extension of the target file.
|
| 168 |
+
* Runs type-safe routing branches:
|
| 169 |
+
* For text formats (.md, .txt), it uses standard safe file system streams.
|
| 170 |
+
* For configuration files (.yaml, .toml), it evaluates whether the data stream is a string or a dict and runs safe serialization tools (yaml.safe_dump or toml.dump).
|
| 171 |
+
* For Microsoft Word structures (.docx), it spawns a clean virtual XML processing model via python-docx.
|
| 172 |
+
* Fires a completion signal to agent_logging.py or returns an explicit error string up to the core loop if a permissions block occurs.
|
| 173 |
+
|
| 174 |
+
3. git_agent.py (The Cloud Courier)
|
| 175 |
+
|
| 176 |
+
**Core Function:** This is your external networking and synchronization engine. It handles all calls to the remote GitHub REST API and coordinates local Git repository staging tree changes via native GitPython bindings.
|
| 177 |
+
|
| 178 |
+
**Relation to app.py & core_logic.py:** This worker is directly wired to the Agentic Control Tower UI panel in app.py. When the human operator clicks Approve & Push to GitHub, app.py bypasses core_logic.py entirely and passes your staged file lists directly into this worker to execute the deployment.
|
| 179 |
+
|
| 180 |
+
**Detailed Operation:**
|
| 181 |
+
|
| 182 |
+
* Reads GITHUB_TOKEN and GITHUB_USERNAME from environment variables, throwing an authentication failure log if missing.
|
| 183 |
+
* Remote Provisioning Check: Hits the GitHub API (/repos/{username}/{repo_name}). If it catches a 404 Not Found, it switches to a POST routine to create a new repository under the user account automatically.
|
| 184 |
+
* Staging & Sync: Safely spins up a local folder called temp_repo/. It clones the destination repository, copies the staged target assets across from your local staging environment (outputs/), tracks changes (repo.index.add), commits the delta with the custom commit message, and pushes the local state up to the origin remote branch.
|
| 185 |
+
* Dynamic Purge (finally block): To ensure zero footprint and prevent disk space buildup, a mandatory shutil.rmtree routine runs at the end of the operation, wiping out the temp_repo/ workspace completely regardless of whether the push succeeded or failed.
|
| 186 |
+
|
| 187 |
+
In a Gist: When a user interacts with CoderG:
|
| 188 |
+
|
| 189 |
+
**app.py** receives the user instruction and kicks off the visual stream.
|
| 190 |
+
|
| 191 |
+
**core_logic.py** thinks, researches, generates the documentation strategy, and sends text back to the screen; calls file_agent.py to stage those files into the local outputs/ workspace.
|
| 192 |
+
|
| 193 |
+
The user clicks approval in the Control Tower, prompting **git_agent.py** to clone down the repository into a temporary folder, transfer the files over, push them to GitHub, and instantly clean up after itself.
|
| 194 |
+
|
| 195 |
+
**agent_logging.py** silently captures every single successful step and edge-case exception along the way to make debugging straightforward.
|
| 196 |
+
|
| 197 |
---
|
| 198 |
|
| 199 |
## π οΈ Tech-Stack & Framework Layering
|
|
|
|
| 224 |
|
| 225 |
---
|
| 226 |
|
| 227 |
+
## User-directed Git Repository Control
|
| 228 |
+
|
| 229 |
+
**The Visual Intimation:** User notified for Git Repo Management
|
| 230 |
+
|
| 231 |
+
The system uses two distinct visual indicators on the interface to signal that it has paused and is explicitly awaiting a human decision:
|
| 232 |
+
|
| 233 |
+
1. The Main Chat Status Intercept
|
| 234 |
+
At the very bottom of the streamed response text in the central chat window, a bold status flag appears:
|
| 235 |
+
|
| 236 |
+
```
|
| 237 |
+
π€ Silicon Architect:
|
| 238 |
+
[Generated content here...]
|
| 239 |
+
|
| 240 |
+
β
Files successfully generated in localized staging environment.
|
| 241 |
+
|
| 242 |
+
β Awaiting authorization control panel to push to GitHub.
|
| 243 |
+
```
|
| 244 |
+
|
| 245 |
+
This is the user's explicit cue. The chat stream stops moving, and the text explicitly tells them that the material has transitioned from a theoretical response to an active, localized artifact awaiting deployment.
|
| 246 |
+
|
| 247 |
+
2. The Control Tower Telemetry Log
|
| 248 |
+
Concurrently, the right-hand panel (π Deployment Telemetry Logs) changes its state. Instead of its initial generic state, it reflects a holding state:
|
| 249 |
+
|
| 250 |
+
```
|
| 251 |
+
_Awaiting local environment staging completion..._
|
| 252 |
+
```
|
| 253 |
+
|
| 254 |
+
> The Human-in-the-Loop Operational Flow
|
| 255 |
+
|
| 256 |
+
Because the application separates Generation (core_logic.py) from Transport (git_agent.py), the workspace naturally freezes in a secure state until a human interacts with it.
|
| 257 |
+
|
| 258 |
+
[ Step 1: Model Streams Content ]
|
| 259 |
+
β
|
| 260 |
+
βΌ
|
| 261 |
+
[ Step 2: Local File Staged Automatically ]
|
| 262 |
+
β
|
| 263 |
+
βΌ
|
| 264 |
+
βββββββββββββββββββββββββββββββββββββββββββββ
|
| 265 |
+
β SYSTEM PAUSES & PRINTS INTERCEPT NOTICE β ββββ User sees "Awaiting authorization..."
|
| 266 |
+
βββββββββββββββββββββββ¬ββββββββββββββββββββββ
|
| 267 |
+
β
|
| 268 |
+
Is the user satisfied?
|
| 269 |
+
β
|
| 270 |
+
ββββββββββββββ΄βββββββββββββ
|
| 271 |
+
βΌ βΌ
|
| 272 |
+
[ YES ] [ NO ]
|
| 273 |
+
β β
|
| 274 |
+
User clicks "Approve User types a adjustment
|
| 275 |
+
& Push to GitHub" prompt in chat box
|
| 276 |
+
β β
|
| 277 |
+
βΌ βΌ
|
| 278 |
+
`git_agent` executes `core_logic` overwrites
|
| 279 |
+
and flushes workspace staging with updated data
|
| 280 |
+
|
| 281 |
+
**In a Gist:**
|
| 282 |
+
|
| 283 |
+
The end-user knows it is time to use the Control Tower because the agent literally concludes its response with an explicit message stating that it is now waiting for their authorization click. If the user is unhappy with the code or document layout on screen, they simply ignore the button, reply with corrections in the chat input, and the agent will overwrite the staged files with the corrected versionsβstarting the approval cycle over again.
|
| 284 |
+
|
| 285 |
+
---
|
| 286 |
+
|
| 287 |
## π Planned & Strategic Enhancements
|
| 288 |
|
| 289 |
### Phase 1: Context Capture Optimizations
|
core_logic.py
CHANGED
|
@@ -128,6 +128,7 @@ def chat_function(message, history):
|
|
| 128 |
)
|
| 129 |
|
| 130 |
response_text = ""
|
|
|
|
| 131 |
# Step 1: Stream the raw LLM output token by token to the user
|
| 132 |
for chunk in completion:
|
| 133 |
if chunk.choices and chunk.choices[0].delta.content:
|
|
@@ -135,33 +136,42 @@ def chat_function(message, history):
|
|
| 135 |
response_text += token
|
| 136 |
yield response_text
|
| 137 |
|
| 138 |
-
#
|
| 139 |
-
|
| 140 |
-
|
| 141 |
-
|
| 142 |
-
|
| 143 |
-
|
| 144 |
-
|
| 145 |
-
|
| 146 |
-
|
| 147 |
-
|
| 148 |
-
|
| 149 |
-
|
| 150 |
-
|
| 151 |
-
|
| 152 |
-
|
| 153 |
-
|
| 154 |
-
|
| 155 |
-
|
| 156 |
-
|
| 157 |
-
|
| 158 |
-
|
| 159 |
-
|
| 160 |
-
|
| 161 |
-
|
| 162 |
-
|
| 163 |
-
|
| 164 |
-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 165 |
|
| 166 |
except Exception as e:
|
| 167 |
yield f"Error: {str(e)}"
|
|
|
|
| 128 |
)
|
| 129 |
|
| 130 |
response_text = ""
|
| 131 |
+
|
| 132 |
# Step 1: Stream the raw LLM output token by token to the user
|
| 133 |
for chunk in completion:
|
| 134 |
if chunk.choices and chunk.choices[0].delta.content:
|
|
|
|
| 136 |
response_text += token
|
| 137 |
yield response_text
|
| 138 |
|
| 139 |
+
# ARTIFACT CHECK: Scan the response text for any code block structures
|
| 140 |
+
# This matches strings enclosed within triple backticks ```
|
| 141 |
+
has_code_blocks = bool(re.search(r"```[\s\S]*?```", response_text))
|
| 142 |
+
|
| 143 |
+
if has_code_blocks:
|
| 144 |
+
# ONLY execute file creation and staging alerts if an artifact is detected
|
| 145 |
+
|
| 146 |
+
# Step 2: Transition seamlessly to Local File Generation
|
| 147 |
+
yield response_text + "\n\nβ _File agent initialized: Generating local documentation workspace..._"
|
| 148 |
+
|
| 149 |
+
from file_agent import write_document
|
| 150 |
+
import shutil
|
| 151 |
+
|
| 152 |
+
filename = "COURSE_README.md"
|
| 153 |
+
backup_filename = "COURSE_README_-1.md"
|
| 154 |
+
|
| 155 |
+
# Proactively manage historical backup copy before writing fresh file state
|
| 156 |
+
src_path = os.path.join("outputs", filename)
|
| 157 |
+
dst_path = os.path.join("outputs", backup_filename)
|
| 158 |
+
if os.path.exists(src_path):
|
| 159 |
+
try:
|
| 160 |
+
shutil.copy2(src_path, dst_path)
|
| 161 |
+
except Exception as e:
|
| 162 |
+
from agent_logging import log_agent_action
|
| 163 |
+
log_agent_action("BACKUP_ERROR", f"Failed to cycle historical version file: {str(e)}")
|
| 164 |
+
|
| 165 |
+
# Write fresh incoming file generation
|
| 166 |
+
file_path = write_document(response_text, filename)
|
| 167 |
+
|
| 168 |
+
print(f"\nGenerated file at: {file_path}")
|
| 169 |
+
|
| 170 |
+
# Step 3: Inform the UI that the material is staged and ready for the GitHub authorization layer
|
| 171 |
+
if "Error" not in file_path:
|
| 172 |
+
yield response_text + f"\n\nβ
_Files successfully generated in localized staging environment._\n\nβ _Awaiting authorization control panel to push to GitHub._"
|
| 173 |
+
else:
|
| 174 |
+
yield response_text + f"\n\nβ _File generation failed: {file_path}_"
|
| 175 |
|
| 176 |
except Exception as e:
|
| 177 |
yield f"Error: {str(e)}"
|
perception_agent.py
CHANGED
|
@@ -39,7 +39,7 @@ def read_image_file(file_path):
|
|
| 39 |
]
|
| 40 |
}
|
| 41 |
],
|
| 42 |
-
temperature=0.
|
| 43 |
)
|
| 44 |
log_agent_action("PERCEPTION_SUCCESS", f"Vision extraction complete for {file_path}")
|
| 45 |
return f"\n--- Visual Content Extraction from {os.path.basename(file_path)} ---\n{response.choices[0].message.content}\n"
|
|
@@ -76,7 +76,7 @@ def read_document_file(file_path):
|
|
| 76 |
paragraphs = [p.text for p in doc.paragraphs]
|
| 77 |
return f"\n--- Document Text Extraction: {filename} ---\n" + "\n".join(paragraphs) + "\n"
|
| 78 |
|
| 79 |
-
# 4.
|
| 80 |
elif ext == '.pdf':
|
| 81 |
log_agent_action("PERCEPTION", f"Initializing pypdf reader pipeline: {filename}")
|
| 82 |
reader = PdfReader(file_path)
|
|
|
|
| 39 |
]
|
| 40 |
}
|
| 41 |
],
|
| 42 |
+
temperature=0.2
|
| 43 |
)
|
| 44 |
log_agent_action("PERCEPTION_SUCCESS", f"Vision extraction complete for {file_path}")
|
| 45 |
return f"\n--- Visual Content Extraction from {os.path.basename(file_path)} ---\n{response.choices[0].message.content}\n"
|
|
|
|
| 76 |
paragraphs = [p.text for p in doc.paragraphs]
|
| 77 |
return f"\n--- Document Text Extraction: {filename} ---\n" + "\n".join(paragraphs) + "\n"
|
| 78 |
|
| 79 |
+
# 4. Portable Document Format (.pdf) Ingestion
|
| 80 |
elif ext == '.pdf':
|
| 81 |
log_agent_action("PERCEPTION", f"Initializing pypdf reader pipeline: {filename}")
|
| 82 |
reader = PdfReader(file_path)
|