Created
November 25, 2025 15:11
-
-
Save Scheevel/aa4bd78b33abe4cd91ff62126862f4b3 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| pick up at archiving story 6.9 | |
| Chat me up, on what it would take to create an adhoc command, that I can execute to go find a particular value on all the drawings? This functionality would leverage the OCR capabilities of the application. | |
| Ok. yes, let's draft a new dev story. Use @docs/completed-epics.md to determine the appropriate name, epic and story number. | |
| Here are concepts I'm imagining. Correct my faulty assumptions: | |
| - we are capturing every readable bit of text on every page? | |
| - we can later go back and query for any value we seek? | |
| - can we do this with a combination of value & confidence? Is confidence part of the OCR-word-soup that will be created? | |
| What ever you UI, you are envisioning for all this. Put at the `/reports` route because currently there is nothing there | |
| Don't change the navigation menu. Keep the reports route button only on the dashboard | |
| Don't change the label of the dashboard button. We are keeping this feature under wraps, so I'm tucking it away at the `reports` route until it is ready for wider usage, it's still very exploratory for now | |
| ↳ @analyst | |
| *elicit more aspects of the functionality described in @ 2.9: | |
| #1 Critique and Refine - Review for flaws and suggest improvements | |
| - | |
| Restate here only the concerns that need clarification, present them in a very concise format | |
| - | |
| Make 1. confidence filter a future story for future iteration | |
| 2. auth is not a concern, it will be added in future iteration | |
| 3. accept limitation | |
| 4. make a backfill script, with a metric of how long it took to run | |
| 5. Elaborate on this, I don't understand | |
| 6. Storage estimates are sufficient for now | |
| 7. defer on performance testing, it will be assessed at a later date | |
| 8. What would error handling look like for the end user? | |
| Additional Q's: | |
| - discoverability will be assessed at a later date | |
| - trigger: I don't understand, please explain | |
| - english only | |
| - | |
| #5 Coordinates are saved, right? As concept, could there be a preview bounding box, so not junking up the drawing with component label, but an ability to navigate to and view the result in the context of the drawing? | |
| #8 Scenario 2: OCR Fails Completely and Log warnings for diagnostics, future to provide indepth analysis of OCR failure for troubleshooting | |
| Elasticsearch: This feature is still very experimental, no extensive use is expected. At a later time we can re-evaluated performance criteria. | |
| - | |
| Choosing option A for #5 (full bounding box) and confirm the bounding box is not visible by default during normal drawing viewing, it is only rendered when selecting to preview from this feature being implemented at the `/reports` route | |
| - | |
| *elicit #3 Agile Team Perspective Shift - Rotate through viewpoints from Dev, QA (keep it simple QA) and Architect to resolve any confusion that emerges | |
| - | |
| Wait, what's the "thumbnail" observation? | |
| - | |
| To clarify, are you proposing a thumbnail for every OCR finding? | |
| - | |
| Agreed. No thumbnail. | |
| Continue *elicit #4 Challenge from Critical Perspective - Play devil's advocate, apply YAGNI principles | |
| - | |
| All those challenges are grasping, so I feel really confident to continue with Version A Original, full scope. | |
| Continue *elicit #6 Tree of Thoughts Deep Dive - Explore multiple implementation paths | |
| - | |
| Regarding Tree of Thought Decision #4 there is only a mention of PDF, I'm assuming the Canvas solution is sufficient for either PDF or images? | |
| - | |
| Great! *elicit #9 Proceed / No Further Actions - Finalize story and prepare for development | |
| ↳ @sm | |
| *story-checklist @ 2.9 Don't try to do too much | |
| - | |
| My preference is to keep it all one story. I can't test "Core search" unless we perform a "backfill" and that is to inform the effectiveness of "visual polish" | |
| ↳ @qa | |
| *test-design @ 2.9 to validate the necessary test scenarios are accounted for (don't over do it) | |
| - | |
| Restate here only the concerns that need clarification, present them in a very concise format | |
| - | |
| Contradiction A. Defer, we want to see if we can make this operational, then we will evaluate perfromance | |
| Contradiction B. Manual testing will determine efffectiveness of backfill | |
| Scope C. streamline to 4 | |
| Missing D. Yes, add PNG & JPEG tests | |
| - | |
| 1 and 2 | |
| ↳ @po | |
| *validate-story-draft @docs/stories/story-2.9-ocr-full-text-search.md and set status to for dev start | |
| - | |
| I think epic 3 already exists, check @docs/completed-epics.md | |
| - | |
| No, although tangential to epic 9, make it it's own epic so it can grow in future scope | |
| Go ahead with your "Required Fix: Option A:" to restructure and match template, it's mostly house keeping so won't impact over all story. What else? | |
| ↳ @dev | |
| *develop-story @ 10.1 you are authorized to begin and follow closely the QA guidance in the story | |
| - | |
| Continue | |
| - | |
| ERROR in ./src/pages/ReportsPage.tsx 7:0-64 | |
| Module not found: Error: Can't resolve '../components/reports/OCRSearchTool' in '/app/src/pages' | |
| - | |
| ↳ @deployer | |
| I've stopped all docker containers, now *smart-deploy @ 10.1 | |
| - | |
| Yes, please run the backfill script | |
| ↳ @dev | |
| create an e2e test spec for @ 10.1 | |
| - Navigate to http://localhost:3000/reports | |
| - Click any component's action to view card | |
| - In "Search Drawing OCR Text" input box type "55" | |
| - Click "Search" action button | |
| - The item that is the the top result (ie Drawing Name = 001-08-201.jpg) | |
| - - click "View" action for that item | |
| - Expected: The application navigates to the drawing where some style of bounding box graphically indicates all the "55" matches | |
| - Reality: The application navigates to the drawing, only the component labels are visible. | |
| Describe to me what the bounding box, should look like. | |
| Evaluate the console or logs for errors | |
| - | |
| Yes, please implement this missing feature | |
| ↳ @bmad-master | |
| Archive @ 6.9 | |
| 1. Review git changes for this and all related x.x documents (git diff, git status) | |
| 2. Update @docs/completed-epics.md: | |
| - If this is the first story for a new epic, add the epic section | |
| - Add this story to the epic's "Stories Completed" list | |
| - Update "Key Files Created/Modified" if significant architecture changes | |
| 3. Remove the story markdown file, once it has been consolidated into the completed-epics.md | |
| 4. Clean up all other story collateral that is no longer needed. | |
| - | |
| That is truly amazing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment