Bug Reporting / System Issues

Hi Brelly Support, I am seeing two related problems in project 96a63fc5-a724-474c-9ff1-29ed88c49fa9 (Leo DeAngelo claim, Allstate claim 0802559369). Co‑Pilot regression reading “DeAngelo Final - Integrity.pdf” Context: In a prior Co‑Pilot conversation on this same project, Co‑Pilot successfully read my final roof estimate file named DeAngelo Final - Integrity.pdf. It parsed line items, totals, and helped build financial breakdowns and carrier correspondence based on that file. In the current Co‑Pilot thread, it can no longer reach that same file, even though I still see it in the Files tab. Symptoms in the current thread: Co‑Pilot calls available_files_retriever_get_available_files. The system returns a very long list of file summaries. The response delivered to Co‑Pilot is truncated: it only includes the beginning and end of the list, not the middle. The entry for DeAngelo Final - Integrity.pdf is not visible in the truncated view, so Co‑Pilot cannot see its File ID. Co‑Pilot then tries files_retriever_get_files using one of the visible File IDs (for example d38c0a63-d6ac-4346-ba0f-fe15434058f3), and gets the message: “No files are currently available.” Later, Co‑Pilot uses files_retriever_get_files on a different File ID (9cf1d722-b960-4b43-9b1b-eeaa305d121e, which is Deangelo Policy.pdf), and that call works. So the content retriever is not completely broken for this project. It works for at least some PDFs but fails or cannot be targeted correctly for DeAngelo Final - Integrity.pdf. Because the tools do not support searching by filename to get a File ID, Co‑Pilot is stuck. It knows a file with that name exists (from earlier work and from what I tell it), but it cannot see the current File ID in the truncated file list and cannot read the estimate content in this thread. Expected behavior: Co‑Pilot should be able to see the DeAngelo Final - Integrity.pdf file in the file list and retrieve its content in any thread attached to this project, just like it did in earlier conversations. The file list that Co‑Pilot receives should not be truncated in a way that hides the ID of a key project file, or there should be a way to search/filter by filename and get the right File ID. File IDs that were valid in earlier sessions should not start returning “No files are currently available” for the same project unless the file was actually deleted. Actual behavior: Co‑Pilot can read some PDFs (for example Deangelo Policy.pdf) but is effectively blind to DeAngelo Final - Integrity.pdf in this thread. It keeps asking me to paste the F9 notes manually because it cannot see or resolve the estimate file, even though it used that exact file successfully in a prior conversation. Request: Please investigate why available_files_retriever_get_available_files is returning a list so large that the middle entries, including DeAngelo Final - Integrity.pdf, are not visible to Co‑Pilot. Either adjust the tool behavior for large projects, or provide a search-by-filename endpoint that Co‑Pilot can use to get the correct File ID. Also check why the File ID d38c0a63-d6ac-4346-ba0f-fe15434058f3 returned “No files are currently available” and whether that indicates a broken mapping for one of my estimate files. The goal is that Co‑Pilot can reliably read DeAngelo Final - Integrity.pdf again, including the F9 notes on line items 2, 15, and 20, without me having to paste them by hand. Duplicate estimate uploads from the Financials tab Separate issue in the same project: In the Financials tab, when I add an estimate, the UI forces me to upload the estimate file even though the same PDF already exists in the Files section. After I upload through Financials, a second file entry with the same filename appears in the main Files list. I end up with two copies of the same estimate in Files with identical filenames. This feels wrong for a couple of reasons: It creates confusion about which “DeAngelo Final - Integrity.pdf” is the “real” one. It increases the surface area for bugs like the one above, since Co‑Pilot and the system now have multiple file objects with the same name. Expected behavior: When I link an estimate from the Financials tab, I should be able to select an existing file from the project instead of being forced to upload a duplicate. If a file with the same name already exists and I upload it again, the system should at least warn me or give me the option to reuse the existing file. Request: Please review the Financials tab behavior so that connecting an estimate to Financials does not silently create duplicate file entries with the same filename in the Files area. Ideally, let me choose an existing estimate PDF that is already uploaded. Thank you for taking a look at both of these issues. Once they are resolved, Co‑Pilot will be able to use my final estimate consistently, and I will not end up with multiple “DeAngelo Final - Integrity.pdf” entries in the same claim.

In the overview tab under policy details, it lists the deductibles as $1 instead of 1% or the actual dollar amount

I've imported my carrier estimate and my supplement estimates but the Financial tab isn't updating with the information.

Copying text from Brelly produces inconsistent results depending on theme (dark vs light) and whether the selection is full or partial. For comparison, copying from ChatGPT (in both dark and light mode) does not introduce wrapper or container styling and preserves clean formatting, which reflects the expected behavior. An attached document is included that demonstrates each condition and its resulting paste behavior for verification. Observed behavior: Dark mode (full or partial selection, highlight -> copy -> paste) * Formatting is preserved * Wrapper or container styling is present * Text appears light gray Light mode (partial selection, highlight -> copy -> paste) * Formatting is preserved * Wrapper or container styling is present * Text appears black Light mode (full selection, highlight -> copy -> paste) * Formatting is preserved * No wrapper or container styling * Text appears black Copy action at bottom of response (any mode) * No formatting * No wrapper or container styling * Text appears black Core issue: There is no consistent way to copy formatted text without also including unwanted UI wrapper styling, except in the specific case of full selection in light mode. Expected behavior: * Copying text (full or partial) should always: * Preserve formatting (lists, spacing, structure) * Exclude UI-specific wrapper or container styling * Normalize text color for readability on light backgrounds Suggested fix: * Ensure that all copy operations strip UI or container-level HTML and only retain semantic formatting * Make copy behavior consistent regardless of: * Theme (dark or light) * Selection scope (partial or full) Secondary suggestion: * Update the copy action at the bottom of responses to default to formatted text without UI styling instead of plain text, so users can copy clean, structured content without losing formatting Impact: Users cannot reliably copy formatted content into emails, documents, or other tools without manual cleanup, especially when copying partial sections or working in dark mode.

https://ai.brelly.com/chat?project_id=0789925f-8f52-44e9-9172-240c596fa048&convo_id=d5fc8f8f-0ccf-4bfe-b79a-6ab5ccc758ea&chat_id=14de8a59-4ad8-421d-a3ad-9b806c4a6885

When uploading a PDF file that contains embedded highlights and comments (annotations), the AI is unable to detect or extract them. Instead, it reports that it can only access the plain text layer of the file. To confirm that the annotations were properly embedded, I uploaded the exact same PDF document to ChatGPT, which was able to fully read and enumerate all of the highlights and comments correctly. This functionality is critically important, especially when evaluating engineering reports, where highlights and comments often contain direct critiques, technical clarifications, or challenges to the engineer’s findings.

Description of Issue: While using Brelly (co-pilot)’s Reference Files feature, I encountered a problem where the AI continued referencing all claim files, even though I had selected only one specific file to isolate. Steps to Reproduce: Opened a claim in Brelly (co-pilot) and accessed the Reference Files pop-up. Selected a single file from the list to use as the reference source. Asked the AI, “Which files are you referencing?” The AI responded that it was referencing all files in the claim instead of only the one I selected. Actions Taken / Observations: I provided the AI with a screenshot of the Reference Files selection window showing the single file I had chosen. I asked why it wasn’t isolating to that file as expected. The AI acknowledged the issue, essentially said "I see what happened, sorry, I’ll fix that,” and appeared to self-correct. After that response, I again asked which file it was referencing, and this time it correctly identified only the file I had selected. Evidence Provided: Screenshots of the conversation with the AI. Screenshot of the Reference Files selection pop-up showing the file that was chosen. Summary: The Reference Files isolation initially failed. The AI ignored the selection and referenced all claim files. After I provided screenshots and pointed out the issue, the AI corrected itself and began referencing only the selected file. This suggests a possible bug in how the initial file selection state is applied or recognized before user intervention.

on the initial "what happened" screen of a claim, the text window can be resized, but doing so can cause the submit button to become inaccessible as it gets moved down and out of view. i was unable to scroll and had to drag the bottom of the main window to extend beyond the bottom of the screen. luckily i have a two monitor setup and was able to view the extended window on the second screen in order to access the submit button. this was after 3+ minute voice to text explanation that i really did not want to lose or have to redo.