DEV Community: Li-Hsuan Lung

Semantic Search — How ProjectBrain Finds What You Mean

Li-Hsuan Lung — Fri, 27 Mar 2026 13:00:00 +0000

The filing cabinet problem

Imagine your project's knowledge base as a massive library with thousands of books, each one containing facts, decisions, and lessons learned by your team. The challenge? There’s no universal catalog. Every book is shelved by whatever label the author thought made sense at the time.

When you need to find something, you rarely remember the exact phrase that was used. You search for "token expiration" and miss the entry titled "auth session handling." You search for "rate limit" and miss the fact logged as "API throttling ceiling is 1000 req/min." The answer is there. You just can’t reach it.

How most search works — and where it falls short

Most search systems operate on exact word matching. The technical term is lexical search.

The idea is simple: take the words in your query, find documents that contain those words, and rank them by how often the words appear.

If you search for "rate limit," you get back entries that literally contain the words "rate" and "limit." If someone logged a fact called "API throttling ceiling is 1000 requests per minute," you won't find it — even though it's exactly what you were looking for.

Lexical search has real strengths. It's fast, reliable, and perfect for exact identifiers. If you need to find a specific ticket number, an error code, or a function name, word-matching is what you want.

But for a knowledge base full of human-authored notes, decisions, and procedures, literal word matching misses half the content.

A different approach: search by meaning

In recent years, semantic search powered by vector embeddings has become accessible and practical for most teams.

Here is the idea. Modern AI models can read a piece of text and produce a numerical fingerprint — a list of hundreds of numbers that represents the meaning of the text. Similar meanings produce similar fingerprints. Different meanings produce very different ones.

When you store a fact in ProjectBrain, we run it through OpenAI's embedding model and save this numerical fingerprint alongside the text. When you search, we fingerprint your query the same way. Then we find the stored entries whose fingerprints are most similar to yours.

Because the fingerprints encode meaning rather than words, this works even when the vocabulary is completely different. "Rate limit," "API throttling ceiling," and "maximum requests per minute" all point to the same region in meaning-space. The search finds all of them.

Here's a real example from our own knowledge base. We logged this fact:

Docker test stage must reset ENTRYPOINT inherited from production stage
When a Dockerfile test stage extends a production base stage that sets ENTRYPOINT, the test stage inherits it. This causes docker compose run to pass the test command as arguments to the production entrypoint instead of executing it directly.

If you search for "run tests locally docker compose", a lexical search on that query finds it because "docker" and "compose" appear in the title. But if you search for "test container starts server instead of running pytest" — which is the actual symptom someone debugging this would type — a lexical search finds nothing. Semantic search finds it immediately, because the meaning of those two descriptions is the same.

The problem with semantic-only search

Semantic search sounds perfect. Why not just use it for everything?

Because it has its own blind spots.

Semantic search relies on your embeddings being up to date. A newly added entry needs to be indexed before it can be found. And the embedding model sometimes misses on very technical content — exact identifiers, version numbers, and project-specific abbreviations that have no semantic neighborhood in the training data.

If someone on our team logged a fact about migration revision 053_task_id_facts_skills, a semantic search for that exact string might rank it lower than other migration-related entries. Lexical search would nail it immediately.

The two approaches are genuinely complementary.

How we combined them

ProjectBrain's search uses both — and then ranks the combined results using four signals. The weights below were tuned empirically against real search sessions on our own knowledge base:

Semantic similarity (55%) is the dominant factor when embeddings are available. It captures meaning, synonyms, and conceptual proximity.

Lexical overlap (25%) handles exact matches — identifiers, code snippets, specific error messages. This is our Elasticsearch-style fallback.

Recency (15%) gives newer entries a boost. A fact logged last week is more likely to be current than one from six months ago.

Task linkage (5%) is a small tiebreaker: entries linked to specific tasks in the project rank slightly higher than general, free-floating knowledge.

What this looks like in practice

Here are two real searches we ran against ProjectBrain's own knowledge base after building this feature.

Query: "run tests locally docker compose"

Rank	Entry	Type	Score
1	Run tests locally using docker compose (matches CI)	Skill	0.58
2	Containerise CI test runs with docker compose	Decision	0.52
3	Docker test stage must reset ENTRYPOINT inherited from production stage	Fact	0.52

The top three results are exactly the three entries we logged earlier that day. They weren't the most recent entries in the system, and they didn't use the same phrasing as the query. But they matched the meaning.

Query: "git hooks enforce lint before push"

Rank	Entry	Score
1	Store git hooks in .githooks/ and activate via core.hooksPath	0.55

A 10-point gap to the next result. No other entry came close.

Why transparency matters

One thing we were careful about: every search result includes a score breakdown. You can see exactly how much of the score came from semantic similarity, lexical overlap, recency, and task linkage.

This matters for a couple of reasons.

First, it builds trust. When an agent retrieves knowledge and acts on it, you want to understand why that entry was selected. "Semantic similarity: 72%, also linked to the current task" is a lot more trustworthy than "it came from the search."

Second, it makes the system debuggable. If a result that should rank first is coming in third, the breakdown tells you exactly which signal is dragging it down. Maybe the entry is old and needs refreshing. That's a fixable problem.

What this means for agents

For AI agents working through ProjectBrain, the search improvement has a direct effect on session startup quality.

When an agent begins a session with an intent — say, "implement the new billing flow" — the context tool now runs a semantic search behind the scenes. Instead of returning the most recently logged entries, it returns the entries most relevant to billing: the rate limit facts, the payment gateway decisions, the deployment skill for this service.

The agent starts with the right context instead of the most recent context. In practice, that means fewer cases of an agent re-discovering something the team already knew, and fewer cases of contradicting a decision that was logged months ago.

If you're already using ProjectBrain, your existing knowledge base is already indexed. The next agent session you run will pull in the most contextually relevant entries for whatever it's working on — not the most recent ones, the most relevant ones. You don't need to do anything.

If you're not yet using ProjectBrain, get started here.

Memory Curation — Keeping the Knowledge Base Honest

Li-Hsuan Lung — Sun, 22 Mar 2026 17:19:32 +0000

The idea I could never get my team to follow

I have always loved the concept of Architecture Decision Records.

The idea is simple: whenever your team makes a non-obvious technical decision, you write a short document. The decision, the context, the alternatives you considered, and why you chose what you chose. You commit it to the repository alongside the code. Future teammates can read it and understand not just what was built, but why.

It is a great idea in theory. But I could never get anyone to actually do it consistently, including myself.

When the decision is fresh in your head, writing it down feels like overhead. When you are under deadline pressure, the ADR file seems like the first thing to skip. By the time the decision feels worth documenting, you have forgotten half the context. And then a new engineer joins, or you revisit the codebase six months later, and you are left reading code with no memory of the reasoning behind it.

ProjectBrain's knowledge base is, at its core, an attempt to make this idea stick — and to extend it beyond just architecture decisions.

Three types of knowledge

ProjectBrain stores three types of knowledge entries:

Decisions are the direct heir of the ADR concept. A decision captures a non-obvious choice, the rationale behind it, and the alternatives that were rejected. The rationale is the most valuable part — it is the part that disappears fastest from human memory and git history.

Here are a few real decisions in our own project's knowledge base:

Adopted Gherkin-style (Given/When/Then) structure for static LLM prompts
Gherkin-style prompts (Given/When/Then) provide a more deterministic structure for LLMs, minimizing ambiguity by clearly separating persona (Given), triggers (When), and expected behavior (Then). Positive framing and scenario isolation have been established as best practices to improve LLM adherence to instructions.

Memory curator v1 is non-destructive
The curator should generate recommendations (refresh, supersede, merge, archive) but should not auto-mutate memory records in v1. Explicit review/resolution preserves safety and auditability.

LLM semantic pass is the centerpiece of the memory curator
The rule-based pass (title normalization, staleness, supersession) acts only as a cheap pre-filter to surface candidates. The LLM pass is the primary signal: it scores semantic duplicate pairs, detects quality issues, and provides the reasoning needed to make recommendations actionable.

Facts are verifiable truths about the project, environment, or system. They have a shorter half-life than decisions — configurations change, services get renamed, constraints shift. A fact that was true last quarter may be silently wrong today.

A few real facts from our knowledge base:

Render render.yaml: dockerContext is relative to rootDir, not repo root
When a service has rootDir set, dockerContext and dockerfilePath are resolved relative to rootDir — not the repo root. Setting dockerContext: ./curator with rootDir: ./curator produces the path curator/curator (not found). The correct value is dockerContext: . when you want the rootDir itself as the build context.

MCP responses support three modes: human, json, both
All tools accept a response_mode parameter ("human" | "json" | "both", default "human"). Human mode returns readable markdown. JSON mode returns a structured envelope: {ok, data, error, meta: {tool, response_mode, query?}}. Both mode returns human text followed by "---" and the JSON envelope. Validate response_mode early via _validate_response_mode() and return the error string if invalid. Always return a string — MCP protocol requirement.

Alembic env.py wraps all migrations in one transaction — a single failure rolls back all

Skills are reusable procedures — the "how we do this here" knowledge that never makes it into a README. Setup guides, debugging playbooks, deployment checklists. The kind of knowledge that lives in a senior engineer's head and gets re-explained to every new teammate.

The combination creates something more complete than ADRs alone: a living record of what is true, what was decided and why, and how things are done.

Agents write without friction

The original ADR problem was that writing felt like a burden. ProjectBrain removes that friction almost entirely for agents — they log knowledge as a natural side effect of doing work. When an agent resolves a bug, it logs the root cause as a fact. When it makes an architectural choice, it logs a decision. When it figures out a deployment step, it logs a skill.

Humans can do the same, and the UI makes it fast. But the real leverage is that agents do it continuously, in the background, without needing to be reminded.

This solves the write problem. But it creates a different one.

The cost of stale memory

When an AI agent reads from a knowledge base, it treats what it finds as ground truth. It does not apply skepticism the way a senior engineer would when stumbling on an old wiki page. It reasons from what it is given.

That is fine when the knowledge base is accurate. It is a serious problem when it is not.

Stale context compounds quietly. An agent reads an old fact about a database schema that was changed three months ago. It proceeds to write a migration against the wrong table structure. Another agent reads a superseded decision about an API design and implements a pattern the team moved away from weeks earlier. The work looks correct on the surface. The errors only surface in review — or in production.

This is worse than no documentation. A missing fact causes the agent to ask a question or make an assumption it flags. A wrong fact causes it to proceed confidently in the wrong direction.

The problem gets worse as the knowledge base grows. More entries means more signal to retrieve. But it also means more outdated entries that look authoritative. The noise is invisible. It is indistinguishable from good signal until something breaks.

How teams typically approach memory pruning

This is not a new problem. A few patterns have emerged, each with real drawbacks.

TTL-based expiry. Give each entry a maximum age. Simple to implement, but crude. A fact about your CI environment might be stale in a week. A foundational architectural decision might be valid for five years. Fixed TTLs either over-prune or under-prune.

Supersession tracking. New entries explicitly mark old ones as superseded. Clean and auditable, but it depends on the writer knowing what the new entry supersedes.

Human-in-the-loop review. Surface aged entries periodically and ask a human to confirm, update, or delete them. The most reliable method, but it does not scale. A team generating dozens of entries per week would spend all its time reviewing the queue.

None of these works well in isolation. The honest answer is that memory pruning requires a mix of strategies — automatic signals to surface candidates, semantic analysis to catch what rules miss, and human judgment for the cases where confidence is uncertain.

What the curator does

ProjectBrain's curator is our current attempt at that mix. We are actively learning what works, and the approach will evolve as we get more data from real usage.

The curator runs on a schedule, currently every 30 minutes, and on each pass it samples a window of recent knowledge entries, applies a rule-based filter as a cheap pre-pass, then sends candidates to an LLM for semantic analysis.

The output is a queue of recommendations:

MERGE — two entries that cover the same ground. Duplicates happen often: one agent logs a fact at the end of a session, another logs the same fact at the start of the next. Or two team members capture the same architectural decision independently after a long discussion.

FLAG — a single entry with a quality problem. A decision with no rationale. A skill with a title but no steps. A fact that references something that no longer exists.

Humans or agents review the queue and act: accept a merge, edit or remove a flagged entry, or dismiss the recommendation if it was wrong.

For FLAG recommendations, the review card offers three actions: Delete, Edit, or Keep. The curator does not know whether a flagged entry should be deleted or just improved — it flags the problem and leaves the decision to the team.

The prompt

The curator's LLM pass sends records as a JSON array and asks for a structured response. The full system prompt:

Given you are a knowledge base curator for a software project management tool
And you review knowledge records (facts, decisions, skills) written by human team members and AI agents
When you receive a JSON array of records containing id, entity_type, title, and body
Then you must return a single JSON object with exactly two keys: "duplicates" and "quality_issues"
And you must output ONLY valid JSON without any markdown formatting or preamble

Scenario: Identifying duplicate records
Given two records have the same meaning but different wording
Then you must include them in the "duplicates" array
And each item must be formatted as:
  {
    "entity_a_id": "...",
    "entity_b_id": "...",
    "confidence": 0.0–1.0,
    "reason": "one sentence — why these are the same",
    "suggested_merged_body": "clean merged content combining the best of both"
  }
And you must only include pairs with confidence >= 0.75
And you must prefer false negatives over false positives
And you must treat two records on related but distinct topics as NOT duplicates

Scenario: Identifying quality issues
Given a record has a genuine quality problem such as:
  - Facts with no body and a title so vague it conveys nothing actionable
  - Decisions with no rationale (just a title, no explanation of why)
  - Skills with no steps or procedure (title only, or body is a single vague sentence)
Then you must flag it in the "quality_issues" array
And each item must be formatted as:
  {
    "entity_id": "...",
    "severity": "low" | "medium" | "high",
    "issue": "one sentence — the specific problem"
  }

A couple of design choices worth noting:

Prefer false negatives over false positives on duplicates. A missed duplicate is low cost — you can find it on the next pass. A false positive that merges two distinct entries destroys information and erodes trust.

Suggest the merged body. For duplicate pairs, the model proposes a merged version combining the best of both entries. This gives the reviewer something to work from rather than asking them to write a new entry from scratch.

Tuning curation behavior

The curator's behavior is configurable per project. You can set a confidence threshold — recommendations below it are suppressed entirely — and a freshness window to flag entries that have not been reviewed within a certain period.

Both settings address the same underlying tradeoff: how much noise you are willing to see in exchange for catching more real problems. A team with a high-churn knowledge base might lower the threshold and accept more false positives. A smaller, stable team might raise it to keep the queue quiet.

What the curator is not

The curator does not auto-apply changes. It does not delete entries or rewrite them without review. All recommendations require confirmation.

We considered auto-merging obvious duplicates, but the false positive cost is too high. Two entries that look nearly identical might cover different contexts. The review step is fast and the downside of getting it wrong is not.

The curator stays in a supporting role. It surfaces candidates. The team decides.

Closing

ADRs work when teams follow them. The hard part has never been the format. It has been the habit.

What ProjectBrain tries to do is make that habit automatic: log continuously as a side effect of work, and let a background process handle the maintenance. The knowledge base stays roughly honest without requiring anyone to remember to tend it.

We are still figuring out the right balance — what to flag, how aggressively to deduplicate, when to trust the LLM's judgment and when to be more conservative. If you are building systems where agents produce persistent memory, the write problem is easy. Plan for curation from the start, and expect to keep tuning it.

A Workflow Engine That Coordinates Work and Makes It Visible

Li-Hsuan Lung — Wed, 18 Mar 2026 13:00:00 +0000

"The future belongs to artificial intelligence."

Ke Jie said this around his 2017 AlphaGo match. He was the world’s top-ranked Go player, and AlphaGo still swept the series 3-0 (games on May 23, May 25, and May 27, 2017), with Ke Jie visibly emotional after the final game.

That story matters to me because I think one day AI may be much closer to solving software development than we ever expected. For a long time, top-level Go was treated as an especially hard frontier where human intuition would dominate for much longer. Then, suddenly, the gap closed fast. I want to treat software development with the same humility and learn from what the systems actually do, not from old assumptions.

That is why this post is about workflow design and visibility.

When people talk about agent workflows, they usually mean one thing: moving tasks from one stage to the next.

In Project Brain, we are building the workflow engine around two goals at the same time: coordinate work reliably, and make agent behavior visible and explainable.

If a task moved from "in progress" to "in review," we should know how it moved, why it moved, and what assumptions were used during that handoff.

What is interesting about our workflow engine

Workflow is a real system object, not prompt text

Our workflow is modeled directly in the platform as stages, statuses, and stage policies. That means teams can edit process behavior in the product itself, instead of hiding process rules inside long prompts.

Stage policy makes behavior explicit

Each stage can define what should happen after successful work: advance and delegate, advance only, terminal completion, or (optionally) reject work back to an earlier stage. In plain terms, we do not hardcode every route in the agent runtime. We store routing intent as workflow policy and execute against it.

Visibility is designed in, not added later

We attach structured metadata to handoffs and status transitions so task history is reconstructable. The focus is not just "current status." The focus is also "execution trace."

That trace is what helps teams improve prompts, policies, and role boundaries over time.

Real examples from team chat (cross-stage communication)

These are real excerpts from Project Brain team messages, showing planner/implementer/reviewer flow. The screenshot thread captures a full loop: blocker report, fix handoff, and approval.

In the screenshots, the reviewer first moved the task back to in-progress with specific blockers:

The implementer then replied with a concrete fix list and commit hash:

Finally, the reviewer confirmed re-review and test outcome:

This is exactly the visibility model we want: not just final status, but the full reasoning chain from failure to resolution.

Why this framing matters

Agents are not programmed in the traditional deterministic sense. You do not write a fixed function and always get the same output. What you can do is influence behavior through constraints, context, and feedback loops. That is why workflow management is so interesting to me: it is a way to shape behavior reliably even when outputs are probabilistic.

If AI systems can improve through iterative play and feedback loops, then our job is to build environments where those loops are observable, testable, and improvable, instead of hidden.

That is exactly why we designed this workflow engine around both coordination and visibility.

If you are not using Project Brain: how to apply this anyway

You can apply the same workflow principles in any stack (Jira + Slack, Linear + GitHub, custom tools, etc.).

Define stage outcomes explicitly.

For each stage, write what "done" means and what should happen next (advance, delegate, reject, or stop).
Use machine-checkable transition guards.

Require expected state/version fields on status changes so race conditions become explicit conflicts instead of silent corruption.
Standardize handoff metadata.

At minimum: task ID, from-stage, to-stage, actor, and reason for handoff.
Treat review feedback as structured data.

Capture blocker reason, fix commit, verification command, and verification result in one thread.
Optimize for replayability.

A new person (or agent) should be able to read a thread and answer: What happened? Why? What changed? Is it verified?

If you can do those five things consistently, you will get most of the value of workflow orchestration plus visibility, even outside Project Brain.

MCP Design in the Real World

Li-Hsuan Lung — Sun, 15 Mar 2026 01:13:45 +0000

When we started Project Brain's MCP server, we followed a common pattern: every new need got a new tool. It felt productive at first. But after a while, the tool menu became crowded, the rules around each tool grew, and the agent got slower at choosing what to call.

That led to more retries, higher token usage, and slower progress on simple tasks. The big lesson was straightforward: after a certain point, adding more tools hurts more than it helps.

In this post, I’ll share what changed for us and what we learned from running this in production.

Motivation: why reduce the number of tools?

1. Tool selection gets harder for the model

Every new tool is another decision branch. Instead of focusing on the task, the model spends effort deciding which tool is "most correct," whether parameters are supported, and whether an older tool has been replaced by a newer one. Those extra decisions show up as wrong calls and wasted turns.

2. Context gets bloated

Each tool adds descriptions, argument rules, and examples. That all has to fit into model context. As context grows, signal gets diluted. Even a strong model performs worse when it has to sift through too many similar options.

3. Day-to-day operations get heavier

Tool growth also creates maintenance overhead: more permission paths to secure, more old behavior to support, more telemetry to monitor, and more docs to keep aligned with reality.

Real examples from Project Brain

1. We moved to a five-tool interface

Instead of exposing many narrow tools, we grouped the public API into five domain entrypoints: projects(...), context(...), tasks(...), knowledge(...), and collaboration(...).

This made the system easier to reason about. The agent picks the right domain first, then chooses an action inside that domain. Fewer top-level choices meant less routing confusion.

2. We added per-turn shortlist routing

We introduced context(action="shortlist", q, limit, full_tool_mode).

Think of it as: "for this user request, show me the best few tool-actions first." For example, if a user asks about milestone planning, shortlist pushes milestone-related operations to the top instead of making the model scan the full catalog every time.

This improved first-call accuracy and reduced unnecessary context.

3. We made responses predictable for machines

For key reads, we added response_mode (human | json | both). In JSON mode, the output always follows the same envelope: ok, data, meta, error.

That simple consistency removed a lot of brittle text parsing and made automation much more reliable.

4. We expanded one task listing tool instead of adding many search tools

Rather than creating separate tools for each search style, we added richer filters to task listing with q_any, q_all, and q_not.

In plain language, one call can now express "must include these terms, can include these terms, and exclude these terms." We got more power without growing top-level tool count.

Challenges you should expect in MCP design

1. Knowing which attributes are actually available

If input rules are vague, agents guess. In our case, task queries used to fail or return partial results because fields looked plausible but were not actually supported.

The fix was to make contracts explicit: clear filter fields, explicit response mode behavior, and stable output shape. Agents should not need to guess what inputs are valid or what outputs will look like.

2. Public listing behind auth token execution

Discovery and execution are different security concerns. During MCP directory integration, we wanted clients to discover capabilities quickly, but we still needed strict auth for real data access.

So we separated the two concerns in middleware: process auth headers and token validation for protected calls, while allowing a small public allowlist for low-risk discovery endpoints. In practice: show the menu publicly, lock the kitchen.

3. Backward compatibility and sprawl

Every new top-level tool creates long-term support cost. Our early habit of adding tiny tools for each new query made routing and maintenance harder over time.

A better pattern was to keep the top-level interface stable and grow capability inside existing domains via actions and parameters. Internal complexity can grow in code modules without forcing public API sprawl.

MCP design best practices

Keep the public tool surface small and stable. Route with shortlist when possible. Prefer extending existing tools over creating new top-level ones. Keep discovery and execution security boundaries separate. Make input and output contracts explicit. Return predictable machine-readable shapes. Prune low-value tools regularly.

Closing

Good MCP design is not about exposing everything. It is about exposing the right minimum, clearly.

If your agents feel flaky, reducing and clarifying your tool surface area is often the fastest way to improve reliability.

The side projects that accidentally started Project Brain

Li-Hsuan Lung — Fri, 13 Mar 2026 05:56:31 +0000

This started with two weekend projects: an AI-powered text adventure experiment and a 3D-printed shelf for my daughter's growing Tomica collection after our trip to Japan. Both sounded fun. Both turned into the same context-management problem.

The pattern I kept hitting

For each new feature, my agent would create more markdown files: TODO lists, feature notes, architecture plans, README updates, and more. At first it felt productive. Then it became its own maintenance project.

Docs drifted from reality faster than I expected. I would see a TODO marked in_progress even though the implementation had already shipped.

When a session crashed, context crashed with it. The next run had no idea where things left off, so momentum disappeared right when I wanted to keep building.

Switching tools meant retraining from scratch every time. Different interface, same project, full re-brief.

That was the moment it clicked: the problem was not model quality. The problem was memory architecture.

Yes, we are dogfooding Project Brain to build Project Brain

We now run our own development through Project Brain. It is extremely meta and only slightly suspicious.

I can swap models and tools without losing momentum because the project state lives in one place, not in whichever chat window happened to be open.

Prompt I use when switching models:

Use Project Brain as your source of truth
1) context(action="session", project_id)
2) tasks(action="context", task_id)
3) tasks(action="list", project_id, status="in_progress")
4) knowledge(entity="fact", action="list", project_id)
5) knowledge(entity="decision", action="list", project_id)

Then summarize:
- current goal
- active tasks
- important constraints/facts
- key decisions and rationale
- immediate next steps

Skills became a force multiplier

One of my favorite side effects has been watching reusable workflows turn into skills. Instead of repeating instructions in every task, we can publish them once and have any agent follow them.

API key auth for service accounts (FastAPI)
Implement GitHub OAuth SSO in FastAPI + React SPA

Following along got dramatically easier

Facts and decisions gave me a clean trail of what changed and why. Instead of diffing stale markdown docs, I can see durable constraints and rationale in structured records.

Team chat made delegation less chaotic

The team chat flow helps agents delegate with context instead of vague instructions. That means fewer handoff bugs and less "wait, what are we doing again?" between planner and implementer agents.

Why I keep saying "we"

I say "we" because the agent has genuinely been a partner in building this product. I regularly ask what would make agents more efficient, what creates friction during execution, and what tooling is missing. Those conversations have directly shaped the roadmap and produced ideas I probably would not have reached alone.

If your agents keep rewriting context and you keep re-explaining the same project, Project Brain was built for that exact pain.