--- date: 2026-04-19 meeting: Enterprise Brain Scrum source: Enterprise Brain Scrum - 2026_04_19 20_01 PDT - Notes by Gemini.txt duration: ~37 minutes --- # Enterprise Brain Scrum — 19 Apr 2026 **Date:** 2026-04-19 | **Time:** 20:01 PDT | **Duration:** ~37 min **Source:** Full transcript ## Participants **RG** — Rajashekar G Mannam **YR** — Yeshwanth Reddy Yerraguntla --- ## Act I — Housekeeping: GitHub Usernames and Screen Share (~00:00 – ~00:04) The session opened with a brief exchange about GitHub usernames. YR had been requesting them repeatedly across calls and wanted all usernames consolidated in one place to avoid the recurring ask. RG agreed and the fix was applied inline. RG then shared his screen to kick off the main discussion. --- ## Act II — UI Feedback Review: Less Text, No Repetition (~00:04 – ~00:08) RG walked YR through the current UI state. YR flagged that the four arrow marks on the right side were not centred properly — a minor layout issue. RG confirmed the area would show "diagrams and charts and everything." RG then summarised the feedback that had already been implemented: > *"Less text need to be given first approach — the direct straightforwardness need to be on the top — and repetition shouldn't be there — like whatever telling in the visualization again it is explaining, previous loop, so that shouldn't be there."* > — RG _(~00:07)_ Two remaining items needed to be resolved by that afternoon: 1. **Perspectives** — implementing the approach discussed earlier. 2. **Confidence score** — showing data source reliability on the UI. YR noted the overall interface felt slow. --- ## Act III — Confidence Score: Design and Architecture Discussion (~00:08 – ~00:20) This was the most substantive discussion of the session. The trigger was RG noting that confidence score needed to appear on the UI, distinguishing data-grounded answers from internet-sourced ones. **YR's position (simplified approach):** - Data from SQL query → 100% confident - Data from internet → confidence is a function of the website scraped > *"What we are currently thinking is we will simply say when it is grounded from data it's 100% confident. Anything else it's not confident."* > — YR _(~00:11)_ **How to show it on the UI** was called out as a **design problem**, not a backend problem. YR gave an analogy: in Vasa (a diagramming tool), adding a comment shows a small bar on the right side. He proposed a similar indicator — green bar for data-grounded, orange for internet-sourced — while explicitly saying "that's a bad idea, but it's one idea" and asking design to take the final call. **RG's concern — mixed sources in one response:** RG pointed out that some answers blend data-grounded content with internet content. He suggested showing a bar indicating "70–80% confident based on these resources." YR pushed back towards simplicity: > *"The whole point is you tell the problem — that we will put the data where it's going to be a mix of grounded data and non-grounded data. Some sentences will be based on that, some on this. How do you clearly differentiate? Said, let them come back — then we'll worry about how to show it."* > — YR _(~00:14)_ **Architectural decision on where confidence lives:** YR proposed attaching confidence as **metadata on the dependency structure**, not as a UI transformation. Every hierarchy of information in the dependency should carry an associated confidence number. Deterministic (SQL) → 100%. Internet → some computed number. The UI agent's job is then to (a) generate the widget and (b) tag it with the confidence number — without transforming that number into a visual itself. > *"You're still not transforming the confidence into a widget in any way. You're still just making the UI agent come up with the right widget, but you're attaching one additional job by saying: for this widget just add this extra confidence number. Let the UI handle how it wants to handle."* > — YR _(~00:18)_ **Source attribution also required:** RG raised that internet sources need to be shown. YR agreed strongly: > *"You have to bring all of them because that is how you will show reliability of Enterprise Brain."* > — YR _(~00:20)_ Multiple sources per answer are expected. --- ## Act IV — Skills Infrastructure: Diwami Agents Repo and Soft Links (~00:20 – ~00:36) YR shifted to showing RG the Diwami agents repository, which serves as a **central skills store**. The goal: any process improvement to a skill should automatically propagate to all engineers without manual copy-paste. Steps walked through live: 1. Clone the Diwami agents repo. 2. Run `make setup-tui` to launch the terminal UI skill manager. 3. Switch to global mode (`T` key) and install **minutes-of-meeting** and **retrospect-and-update** skills. 4. Do the same for GitHub Copilot. YR explained the intent: skills installed globally via the TUI are available in any repo without copying files. When a skill is improved and a PR is merged on the Diwami agents repo, everyone gets the update on next pull. **Soft link vs copy:** When a bug in the TUI prevented local skill installation, YR gave RG a manual shortcut: ```bash ln -s "" ~/.claude/skills/daksh ``` This creates a symlink from the global Claude skills directory to the versioned skill source, achieving the same "single source of truth" property without needing the TUI to work. > *"Skills should always be soft links. They should never be literal copy-pasted folders."* > — YR _(~00:35)_ YR confirmed he would fix the TUI bug and provide a cleaner flow the next day. --- ## Act V — Interactive Charts: TRD Required Before Proceeding (~00:27 – ~00:36) RG introduced the interactive charts work. The concept: - Current widgets are static; each widget has metadata describing its content. - The new approach adds an **emit** capability to widget metadata — output from one widget becomes the input filter for another (e.g., clicking a bar in a bar chart filters a linked line graph). - Abhilash had done initial research and RG reported progress on implementing this. YR stopped RG before the implementation discussion went further: > *"See, this is a TRD, Rajar. We can't go implementing it without actually having a proper technical discussion. So better you put it in a markdown file, put it on Vasa saying this is how the TRD is going to look like."* > — YR _(~00:29)_ RG agreed to write the TRD that day. YR then walked RG through using the **Daksh skill** (`/daksh`) to generate the TRD document in the Enterprise Brain repo, bypassing the standard Daksh pipeline stages and going straight to TRD generation. The skill pulled existing context from repo documents and began scaffolding the TRD. The session ended with YR saying he had another meeting and dropping off. --- ## Todos - [ ] Write TRD for interactive charts (widget emit/filter interaction model) and post to Vasa | author: Rajashekar G | deadline: same day (2026-04-19) - [ ] Fix TUI bug in Diwami agents repo for local skill installation | author: Yeshwanth Reddy Yerraguntla | deadline: next day (2026-04-20) - [ ] Add confidence metadata (source field) to dependency structure for each widget/packet | author: Rajashekar G | deadline: unspecified - [ ] Implement source attribution — show all internet sources alongside internet-sourced answers | author: Rajashekar G | deadline: unspecified - [ ] Install minutes-of-meeting and retrospect-and-update skills globally (and via soft link for Enterprise Brain repo) | author: Rajashekar G | deadline: unspecified