Anirud/add rag context to chat thread (#199)

* copy run agent container + helper func

* copied in updated docker views

* copied in model utils to stream agent response

* copy in model views

* added agent view

* copy in all frontend components

* add search api key to docker compose yml

* copy in updated model urls

* added requirements for dockerfile

* rename hf_model_id

* remove commetned code intepretor tool

* added fix so agent works with other llama models

* fix requirements in dockerfile

* add thread id to match stateful chat

* add readme

* add agent workflow diagram

* Update README.md

* Delete app/api/agent_control/Agent.png

* Add files via upload

* Delete app/api/agent_control/Agent.png

* Add files via upload

* Update README.md

* Delete app/api/agent_control/Agent.png

* Add files via upload

* Delete app/api/agent_control/Agent.png

* Add files via upload

* Update README.md

* fix link href (#180)

* refactor(chat history component): improve file handling and add RAG support

- Add RAG datasource integration with metadata display
- Create reusable FileDisplay component for file management
- Implement FileViewerDialog for improved file preview experience
- Support both image and non-image file types with download option
- Clean up file handling logic and separate from image-specific code
- Add visual indicator for RAG-enabled messages

* Show RAG pill based on the message's stored RAG context

* feat(add support in chat component):
- Use the RAG datasource from the message if available

* move image display to its own component

* include rag source name when selected

* refactor(types): clean up and organize type definitions
- Remove redundant and commented-out interfaces
- Group related interfaces together (chat, inference, file, voice)
- Add proper JSDoc comments for better documentation
- Consolidate duplicate type definitions
- Add explicit typing for RAG-related interfaces

* add pdfjs-dist to test

* feat: improve file display
- show images in better aspect ratio

* display file display for images ,code files and other file types

* add icons for file display in chat thread

* extend types

* extend to add
- File extensions mapping for code files and other file types

* extend to allow for files to be passed as text

* fix alignment

* limit upload to a single image file

* set focused state in input area

* feat: add ability to process multiple code and or text file types and send to model

* re add resizing input are

* fix copy button logic

* Anirud/update vllm setup steps (#189)

* update readme to reflect new flow

* fix readme issues

* add Supported models tab:
pointing to tt-inference-server readme

* docs: Update main readme
- add better quick start guide 
- add better notes for running in development mode

* docs: re add Mock model steps

* docs: fix links

* docs: fix vllm

* Update HowToRun_vLLM_Models.md


* Update HowToRun_vLLM_Models.md

CONTRIBUTING.md

@@ -1,106 +1,129 @@
-# Contributing to TT-STUDIO
+# **Contributing to TT-STUDIO**
 
-Thank you for your interest in this project! We want to make contributing as easy and transparent as possible.
+Thank you for your interest in this project! We aim to make the contribution process as easy and transparent as possible.
 
-If you're interested in making a contribution, please familiarize yourself with our technical [contribution standards](#contribution-standards) outlined in this guide.
+If you’d like to contribute or have suggestions , please familiarize yourself with technical [contribution standards](#contribution-standards) outlined in this guide.
 
-Next, request the appropriate write permissions by [opening an issue](https://github.com/tenstorrent/tt-studio/issues/new/choose) for GitHub permissions.
+---
+
+## **Contribution Requirements**
+
+- **Issue Tracking:**
 
-All contributions require:
+  - File a feature request or bug report in the Issues section to notify maintainers.
 
-- An issue:
-  - Please file a feature request or bug report under the Issues section to help get the attention of a maintainer.
-- A pull request (PR).
-- Your PR must be approved by the appropriate reviewers.
+- **Pull Requests (PRs):**
+  - All changes must be submitted via a PR.
+  - PRs require approval from the appropriate reviewers before merging.
+
+---
 
-## Contribution Standards
+## **Contribution Standards**
 
-### Code Reviews
+### **Code Reviews**
 
 We actively welcome your pull requests! To ensure quality contributions, any code change must meet the following criteria:
 
 - A PR must be opened and approved by:
   - A maintaining team member.
   - Any codeowners whose modules are relevant to the PR.
-- Run pre-commit hooks.
-- Pass all acceptance criteria mandated in the original issue.
-- Pass the automated GitHub Actions workflow tests.
-- Pass any testing requirements specified by the relevant codeowners.
+- Run **pre-commit hooks**.
+- Pass all **acceptance criteria** mandated in the original issue.
+- Pass the **automated GitHub Actions workflow tests**.
+- Pass any **testing requirements** specified by the relevant codeowners.
 
-### **Git Branching Strategy Overview**
+---
 
-### **1. Main Branches:**
+## **Git Branching Strategy Overview**
 
-- **`main`**: Holds production-ready code.
+### **1. Main Branches**
 
-  - **Rules:**
+- **`main`** – Holds production-ready tagged code.
 
+  - **Rules:**
     - No force pushes.
+    - Requires **rebase and merge** or **squash and merge** from a release cut branch.
 
-    - Requires rebase and merge.
-
-- **`dev`**: The central branch where all feature branches are merged and validated before preparing for release cut branch.
-
+- **`dev`** – The central branch where all feature branches are merged and validated before preparing a release branch.
   - **Rules:**
-
     - No force pushes.
-
-    - Requires squash merge.
+    - Requires **squash merge** from a feature branch.
 
 ---
 
 ### **2. Feature Development Workflow**
 
 #### **Development Process**
 
-- Developers create feature branches from `main` to work on new features or bug fixes.
-- Once a feature is completed and reviewed, it is **squash merged** into `dev` to maintain a clean history.
+- **Feature Branches:**
+
+  - Created from `dev`.
+  - **Naming convention:** `dev-name/feature` or `dev/github-issue-number`.
+    - Example: `dev-john/new-feature` or `dev-john/1234`.
+
+- **Merging to `dev`:**
+  - Once completed and reviewed, feature branches are **squash merged** into `dev` to maintain a clean history.
 
 ---
 
+### **3. Release Process**
+
 #### **Release Preparation**
 
-- When `dev` is stable and ready for release, a **release cut branch** (e.g., `release-v1.xxx`) is created from `dev`.
-- Developers **cherry-pick** their completed and validated features from `dev` into the release branch.
-- The release branch is tested before deployment.
+- **Creating the Release Branch:**
+
+  - When `dev` is stable and ready for release, a **release cut branch** is created from `main`.
+  - **Naming convention:** `rc-vx.x.x` (e.g., `rc-v1.2.0`).
+
+- **Feature Inclusion:**
+
+  - Developers **cherry-pick** validated features from `dev` into the release branch.
+  - Test and resolve any **merge conflicts** as needed.
+
+- **Testing & Fixes:**
+  - The release branch undergoes **testing before deployment**.
+  - **Bug fixes and PR comments** follow the standard development flow and can be cherry-picked into the same release branch.
 
 ---
 
 #### **Final Deployment**
 
-- Once the release branch is validated, it is merged into `main` for production deployment.
-- Merging to `main` requires **at least two approvals** to ensure code quality and stability.
-- After merging, the release is tagged following semantic versioning (e.g., `v1.0.0`).
+- After validation, the **release branch is merged into `main`** for production.
+- **At least two approvals** are required for merging to `main` to ensure quality.
+- Merging can be done via **rebase and merge** or **squash and merge** if multiple commits were cherry-picked.
+- The release is **tagged following semantic versioning** (e.g., `v1.0.0`).
 
 ---
 
-#### Git Tagging
-
-- Tags are created in main to mark production releases.
+### **4. Git Tagging**
 
-- [Semantic versioning (e.g., v1.0.0) is used to track different versions.](#versioning-standards)
+- **Tags are created in `main`** to mark production releases.
+- **Semantic versioning** (e.g., `v1.0.0`) is used to track different versions.
 
 ---
 
-### Versioning Standards
+## **Versioning Standards**
 
-To ensure consistency in versioning, we follow the principles of **semantic versioning**:
+To ensure consistency, we follow **semantic versioning** principles:
 
-- **MAJOR**: Increment for incompatible or breaking changes to backend or frontend APIs or functionality:
+- **MAJOR**: Increment for **breaking changes** to backend or frontend APIs or functionality.
 
   - Removing or significantly altering existing features.
-  - Changing the current networking design.
-  - Altering backend API flows.
-  - Changing frontend API calls and/or redoing entire components.
+  - Changing the networking design.
+  - Modifying backend API flows.
+  - Redesigning frontend API calls or components.
 
-- **MINOR**: Increment when adding new features or capabilities in a backward-compatible manner:
+- **MINOR**: Increment for **new features** or capabilities that are **backward-compatible**.
 
-  - For example, supporting new models like YOLOv4 or adding new functionalities.
+  - Example: Supporting new models like YOLOv4 or adding additional functionalities.
+  - If the current version is `1.2.3` and a new **minor** release is introduced, it becomes **`1.3.0`**.
+  - If additional patches are needed after `1.3.0`, the version will increment to **`1.3.1`**, **`1.3.2`**, and so on.
 
-- **PATCH**: Increment for bug fixes and minor improvements that are backward-compatible.
+- **PATCH**: Increment for **bug fixes and minor improvements** that are **backward-compatible**.
+  - If patches are applied to `1.2.3`, the next versions would be `1.2.4`, `1.2.5`, etc.
 
 ---
 
-### FlowChart for our Git Branching Strategy
+## **Git Branching Strategy Flowchart**
 
 <img src="Git-management.png" alt="Git Branching Strategy" width="600" />