A practical plan for helping Ditto understand its own product, changes, docs, and issue history over time.
Ditto should not just answer from general memory and web context. It should have a first-class internal product knowledge layer built from:
• automated user issue triage submitted through file_feedback_for_team
• release notes generated every ship cycle
• product docs and feature specs
• app/version metadata
• curated changelog summaries
That gives the backend Ditto agent a searchable, retrieval-friendly understanding of:
• what shipped • what changed • what is broken • what is planned • what matters for a specific user question
Right now Ditto is becoming deep enough that the product surface is outrunning the assistant’s internal understanding.
This creates a gap:
• the team knows what changed • the codebase knows what changed • the docs partly know what changed • but Ditto itself does not always know the most relevant product truth at answer time
The goal is to make Ditto progressively better at:
• answering product questions accurately • grounding support answers in actual shipped behavior • referencing the most relevant version changes • understanding regressions and known issues over time • surfacing docs, release notes, and feature context procedurally via seed-memory-style retrieval
Use four source types:
Every meaningful bug report / feature request created via file_feedback_for_team should produce a normalized internal record.
Suggested fields:
• feedback_id
• created_at
• product_area
• category (bug, feature, improvement, other)
• severity / impact
• user-facing summary
• expected behavior
• actual behavior
• reproduction steps
• linked GitHub issue / PR
• status (new, triaged, in progress, shipped, closed, won’t fix)
• fixedinversion
This becomes the raw support truth layer.
Every release should produce structured release notes, not just prose.
Suggested fields:
• version
• date
• app(s) affected (ditto-app, backend, ditto-admin, etc.)
• feature entries
• bug fix entries
• breaking changes
• notable internal changes
• linked issues / PRs / docs
• user-facing summary
• support-facing summary
• searchable embeddings / retrieval text
Ingest:
• docs pages • internal specs • feature launch notes • roadmap notes when appropriate • support playbooks / known issue docs
Maintain a machine-readable capabilities snapshot so Ditto knows the current truth about itself.
Examples:
• reminders: not supported yet • recurring tasks: not supported yet • GitHub issue filing: supported • calendar event creation: supported • release notes browsing: supported/not supported • Ditto Code live steering: supported
This reduces stale or hallucinated product claims.
My recommendation:
Keep release notes close to the product repo and release pipeline, then mirror them where needed.
Recommended structure:
• canonical release-note markdown/JSON lives in a repo-controlled location • GitHub Releases can publish the polished user-facing version • backend ingests the structured form for search and retrieval
ditto-app releasesPros:
• easiest to wire into current shipping flow • versioned with the app • natural public surface • works well with GitHub Releases and semantic-release
Cons:
• less ideal once release notes span multiple repos/products • backend-specific or cross-product changes may get awkward
Pros:
• cleaner for multi-product release aggregation • easier to treat as a knowledge corpus • can hold structured metadata + generated prose + docs links
Cons:
• more operational overhead • weaker coupling to the actual shipping pipeline unless enforced well
Start with a canonical structured changelog generated from the shipping repos, then later split into a dedicated release-notes repo only if cross-product scale demands it.
In other words:
• do not over-separate too early • do build the data model now so migration later is easy
The best version is not hand-written-only and not AI-only.
Use a hybrid pipeline:
• merged PRs • commit history • labels • linked issues • milestone/version tag • manually highlighted launches • docs/spec references
Produce two outputs every release:
• human-facing release notes • machine-facing release facts
That second output is what makes Ditto smarter over time.
The backend Ditto agent should treat product self-knowledge as a first-class retrieval layer.
Recommended retrieval order for product/support questions:
This helps Ditto answer questions like:
• “Does Ditto support X?” • “Was this bug already fixed?” • “What changed in the latest version?” • “Why is my workflow stuck?” • “What did you ship this week related to agents?”
This is the strongest part of your idea.
You already have the concept of seed memories: preselected context snippets that help the model start from the right local truth.
Apply the same concept to self-knowledge retrieval.
For a given user query, retrieve a small set of high-value “product seeds,” such as:
• the most relevant release note entry • the most relevant known issue / bug status item • the most relevant doc section • the most relevant feature/spec summary • the current capability status record
Then feed those into the prompt as structured product seeds.
If the user asks:
“Why is my Ditto Code workflow stuck in running?”
Product seeds might include:
• known issue: workflow dispatch stalls • release note: worker startup optimization changes • support doc: expected workflow states • capability record: workflow execution supported, recurring scheduling not supported
That gives Ditto grounded, recent, product-aware answers instead of vague guesses.
Use a shared internal schema for all self-knowledge objects.
Suggested top-level types:
• feedback_report
• known_issue
• release_note
• feature_capability
• doc_section
• support_playbook
• roadmap_item
Shared fields:
• id
• type
• title
• summary
• body
• source_repo
• source_url
• created_at
• updated_at
• effective_version
• product_area
• tags
• status
• related_ids
• embedding_text
This makes unified retrieval much easier.
The agent does not need raw entire repos by default. It needs the distilled searchable layer.
Recommended backend-accessible indices:
• release notes index • known issues index • docs/specs index • capability registry index • optional issue-to-fix lineage index
Then add a retrieval function like:
search_product_knowledge(query, filters)
Possible filters:
• product area • version • status • source type • date range
This is where file_feedback_for_team becomes especially valuable.
Ideal loop:
That gives Ditto longitudinal understanding instead of one-off memory fragments.
This can also power visible product features.
Use the same release corpus for:
• About page release notes • contextual “what changed” cards • feature education • upgrade highlights
When users ask product questions, Ditto can cite:
• shipped version notes • known issue status • docs pages
The same corpus helps:
• support • onboarding • marketing recaps • weekly shipped tweets • roadmap sync • documentation upkeep
• define schemas
• normalize file_feedback_for_team output into a durable dataset
• generate structured release note artifacts per version
• ingest docs into a searchable index
• add backend search across release notes / docs / known issues • add product-seed retrieval for relevant user queries • prioritize capability checks before freeform answering
• link feedback → issue → PR → release note → fix version • auto-suggest relevant known issues during support chats • auto-suggest release-note/doc updates when a feature ships
• Ditto explains itself with version awareness • Ditto can compare “before vs after” behavior by version • Ditto becomes materially better at answering product, support, and onboarding questions
Build a structured self-knowledge layer where feedback, release notes, docs, and capabilities are all indexed for retrieval — then use seed-memory-style product seeding so Ditto can answer product questions from the right internal truth, not just generic model knowledge.
If you want to move fast, I’d do these next:
• define the schema for release_note, known_issue, and feature_capability
• decide the canonical release-note storage location
• wire file_feedback_for_team outputs into a durable triage table
• generate structured release notes for the latest few versions
• expose backend retrieval over release notes + docs + known issues
• add product seeds to the Ditto backend prompt assembly
A good way to talk about this internally:
Ditto needs a memory of its own product evolution.
Or more concretely:
We are building Ditto’s self-knowledge layer so the assistant understands its current capabilities, recent changes, known issues, and relevant docs as deeply as it understands the user.