Product discussion: interactive owner conversations

free commented

2026-06-02 10:39:50 +01:00

Owner

This issue captures a planning conversation about adding an interactive way to talk with the owner agent and file issues from that discussion.

It is deliberately not a workflow intake item. It carries only the product label; there is no untriaged label, so it should not enter the dogfood workflow.

This issue captures a planning conversation about adding an interactive way to talk with the owner agent and file issues from that discussion. It is deliberately **not** a workflow intake item. It carries only the `product` label; there is no `untriaged` label, so it should not enter the dogfood workflow.

free added the

epic

product

labels

2026-06-02 10:39:50 +01:00

free commented

2026-06-02 10:39:53 +01:00

Author

Owner

I'd like to ba able to connect and talk to the owner agent interactively. The main use case for now is discussing with him new features to add, be sure we are on the same page and have him file issues on my behalf. What do you think is the best way to achieve that? Note that initially we'll do this via the dogfood setup under examples/

owner commented

2026-06-02 10:39:55 +01:00

Collaborator

Best approach: don’t repurpose the existing owner workflow worker. Today that agent is a one-shot queue worker with a closed action set: merge, alignment, or human escalation. For interactive feature discussion, add a separate owner conversation surface.

Recommended shape:

Open or create a Forgejo issue like Owner chat labeled harness-chat; it is not part of the workflow and should not have untriaged.
Let the user chat in the terminal; user turns are posted with the human/user identity, owner replies with the owner identity.
Use a new owner_chat prompt, not the current narrow owner workflow prompt.
File issues only after explicit confirmation. The model proposes drafts; /file 1 creates a normal intake issue labeled untriaged and links it back to the chat thread.

Why this is better: it dogfoods Forgejo as the durable collaboration surface, keeps normal workflow agents unchanged, avoids broad mutation power, and preserves the architect as the delivery breakdown role.

MVP path: add harness-agents::owner_chat, a harness-owner-chat binary, and wire examples/reference-delivery/run.sh owner-chat to source role tokens, create the transcript issue, and file idempotent intake issues.

Best approach: don’t repurpose the existing `owner` workflow worker. Today that agent is a one-shot queue worker with a closed action set: merge, alignment, or human escalation. For interactive feature discussion, add a separate owner conversation surface. Recommended shape: 1. Open or create a Forgejo issue like `Owner chat` labeled `harness-chat`; it is not part of the workflow and should not have `untriaged`. 2. Let the user chat in the terminal; user turns are posted with the human/user identity, owner replies with the owner identity. 3. Use a new `owner_chat` prompt, not the current narrow owner workflow prompt. 4. File issues only after explicit confirmation. The model proposes drafts; `/file 1` creates a normal intake issue labeled `untriaged` and links it back to the chat thread. Why this is better: it dogfoods Forgejo as the durable collaboration surface, keeps normal workflow agents unchanged, avoids broad mutation power, and preserves the architect as the delivery breakdown role. MVP path: add `harness-agents::owner_chat`, a `harness-owner-chat` binary, and wire `examples/reference-delivery/run.sh owner-chat` to source role tokens, create the transcript issue, and file idempotent intake issues.

free commented

2026-06-02 10:39:56 +01:00

Author

Owner

what do you mean with "Later, we can add a background serve mode that watches Forgejo comments/webhooks, so you can talk to the owner directly from the Forgejo UI too." ? what would the initial MPV look like in practice (explain the flow) and what would a later phase look like instead?

free commented

2026-06-02 10:39:57 +01:00

Author

Owner

I like the idea and the flow, I'm just not sure if Forgejo is the best platform for something that feels interactive. It's surely nice to have Forgejo capture the whole interactive session as an issue after the session completes (or even better while the session runs), but maybe there are better solutions for the interactive part? I guess forgejo doesn't have any "extensions" that are good fit? Or maybe it could be integrated with some external web-based chat system. Please think about that, you also have web search tools if you feel you need them.

owner commented

2026-06-02 10:39:58 +01:00

Collaborator

Forgejo should be the system of record, not necessarily the live chat UI.

Initial MVP would be a synchronous CLI chat:

cd examples/reference-delivery
./run.sh owner-chat

The user types in the terminal, the owner replies in the terminal, and every turn is mirrored into a Forgejo issue. /file 1 creates a real workflow intake issue labeled untriaged; the chat session issue is labeled e.g. owner-chat, not untriaged.

Later “serve mode” would be a daemon that watches Forgejo issue comments/webhooks. You would open a special “Owner chat” issue in Forgejo, comment there, and the owner bot would reply as comments. That makes Forgejo itself the chat UI, but it is more asynchronous and less pleasant than a real chat surface.

For richer interaction, a local web chat app is probably better: real chat layout, draft issue cards, “File issue” buttons, transcript synced to Forgejo, and created intake issue links. Matrix/Zulip/Mattermost/etc. bridges are good if the team already lives there, but too much infrastructure for the first dogfood version.

Recommendation: terminal ./run.sh owner-chat first, then a small local web chat UI, optionally later a Forgejo comment bot or Matrix/Zulip bridge.

Forgejo should be the system of record, not necessarily the live chat UI. Initial MVP would be a synchronous CLI chat: ```sh cd examples/reference-delivery ./run.sh owner-chat ``` The user types in the terminal, the owner replies in the terminal, and every turn is mirrored into a Forgejo issue. `/file 1` creates a real workflow intake issue labeled `untriaged`; the chat session issue is labeled e.g. `owner-chat`, not `untriaged`. Later “serve mode” would be a daemon that watches Forgejo issue comments/webhooks. You would open a special “Owner chat” issue in Forgejo, comment there, and the owner bot would reply as comments. That makes Forgejo itself the chat UI, but it is more asynchronous and less pleasant than a real chat surface. For richer interaction, a local web chat app is probably better: real chat layout, draft issue cards, “File issue” buttons, transcript synced to Forgejo, and created intake issue links. Matrix/Zulip/Mattermost/etc. bridges are good if the team already lives there, but too much infrastructure for the first dogfood version. Recommendation: terminal `./run.sh owner-chat` first, then a small local web chat UI, optionally later a Forgejo comment bot or Matrix/Zulip bridge.

free commented

2026-06-02 10:39:59 +01:00

Author

Owner

would you build the web app from scratch in-house, or do you think there are suitable pre-made options? please assess the situation and tradeoffs

owner commented

2026-06-02 10:40:00 +01:00

Collaborator

Build the first web app in-house, but keep it very small: a local web console, not a product frontend.

Pre-made chat apps solve “talk to an LLM provider”; this needs “talk to a product-owner agent that can safely draft and file workflow intake issues.” The Harness-specific behavior is the hard part: mirror every turn into Forgejo, show draft issue cards, require explicit confirmation, create untriaged intake issues idempotently, link filed issues back to the chat session, use role tokens safely, and keep the LLM behind a constrained owner-chat prompt.

Assessment:

Tiny in-house web UI: best MVP fit; some UI work, but total control and low infra.
Open WebUI / LibreChat: good generic LLM UX; heavy, extra auth/storage, custom issue-filing flow.
Matrix/Zulip/Mattermost bot: good if already used; still needs custom transcript-to-Forgejo and filing logic.
Forgejo comments only: great audit trail; poor interactive UX.
React chat UI libraries: good later accelerator; still need the Harness backend.

Recommended dogfood path: small Rust-backed local web app with one static HTML/JS page, POST /message, POST /file-draft, Forgejo transcript issue as storage, and local browser as the interactive surface. Pre-made components can enter later if the UI grows.

Build the first web app in-house, but keep it very small: a local web console, not a product frontend. Pre-made chat apps solve “talk to an LLM provider”; this needs “talk to a product-owner agent that can safely draft and file workflow intake issues.” The Harness-specific behavior is the hard part: mirror every turn into Forgejo, show draft issue cards, require explicit confirmation, create `untriaged` intake issues idempotently, link filed issues back to the chat session, use role tokens safely, and keep the LLM behind a constrained owner-chat prompt. Assessment: - Tiny in-house web UI: best MVP fit; some UI work, but total control and low infra. - Open WebUI / LibreChat: good generic LLM UX; heavy, extra auth/storage, custom issue-filing flow. - Matrix/Zulip/Mattermost bot: good if already used; still needs custom transcript-to-Forgejo and filing logic. - Forgejo comments only: great audit trail; poor interactive UX. - React chat UI libraries: good later accelerator; still need the Harness backend. Recommended dogfood path: small Rust-backed local web app with one static HTML/JS page, POST `/message`, POST `/file-draft`, Forgejo transcript issue as storage, and local browser as the interactive surface. Pre-made components can enter later if the UI grows.

free commented

2026-06-02 10:40:01 +01:00

Author

Owner

I already have a Matrix setup, but I'm not entirely sure it offers a good UX for this use case. Eventually I'd like to also 1) be able to run this from an Android phone (so an Android app version would be needed) 2) be able to do this over interactive voice live sessions (perhaps intergrated with the visuals).

owner commented

2026-06-02 10:40:02 +01:00

Collaborator

Use Matrix as an early text/mobile frontend, but don’t bet on Matrix as the final rich interactive UX.

Durable architecture:

CLI / Matrix bot / Web app / Android app / Voice UI
                ↓
        Owner conversation service
                ↓
   Forgejo transcript + filed intake issues

Near-term Matrix MVP: DM or room with @harness-owner; the bot mirrors the session into a Forgejo “owner chat transcript” issue; /file 1 creates a real untriaged intake issue. This gives Android access immediately through Element or another Matrix client.

Matrix pros: existing setup, Android UX now, persistent rooms/history, notifications, lightweight text discussion. Cons: draft issue cards are markdown/text, confirmations are commands/reactions, widgets are client-dependent, live voice with an AI participant is non-trivial, encrypted rooms add bot key/storage complexity.

Better later UX: a web/PWA with visual draft cards, buttons, issue links, live transcript, and eventually voice. Avoid native Android until the workflow stabilizes; a PWA or wrapper likely gets most of the value faster.

Voice roadmap: start with push-to-talk/voice notes, then live voice in the web/PWA using WebRTC or STT→LLM→TTS, then consider MatrixRTC/Element Call integration later.

Use Matrix as an early text/mobile frontend, but don’t bet on Matrix as the final rich interactive UX. Durable architecture: ```text CLI / Matrix bot / Web app / Android app / Voice UI ↓ Owner conversation service ↓ Forgejo transcript + filed intake issues ``` Near-term Matrix MVP: DM or room with `@harness-owner`; the bot mirrors the session into a Forgejo “owner chat transcript” issue; `/file 1` creates a real `untriaged` intake issue. This gives Android access immediately through Element or another Matrix client. Matrix pros: existing setup, Android UX now, persistent rooms/history, notifications, lightweight text discussion. Cons: draft issue cards are markdown/text, confirmations are commands/reactions, widgets are client-dependent, live voice with an AI participant is non-trivial, encrypted rooms add bot key/storage complexity. Better later UX: a web/PWA with visual draft cards, buttons, issue links, live transcript, and eventually voice. Avoid native Android until the workflow stabilizes; a PWA or wrapper likely gets most of the value faster. Voice roadmap: start with push-to-talk/voice notes, then live voice in the web/PWA using WebRTC or STT→LLM→TTS, then consider MatrixRTC/Element Call integration later.

free commented

2026-06-02 10:40:03 +01:00

Author

Owner

okay, please file this conversation as issue in Forgejo, to get a feel of the Forgejo "dump" part. use the owner credentials for your turns and my own credentials for my turns, look at examples/dogfood to figure out the auth/target-forgejo details. Label the issue as "product" and make sure the bot doesn't relabel it as "untriaged" and start processing it

architect removed the

epic

label

2026-06-02 10:41:21 +01:00

Rows
Columns

Product discussion: interactive owner conversations #3