The workspace context

The Context page is what every agent on this workspace is briefed with. The code calls it the workspace brain; the interface calls it Context everywhere.

It holds five pieces of prose and five lists. Each list is a real table with real rows — not a document.

The three kinds of knowledge

Every technology and every standard carries where it came from. This is the most important idea on the page.

Source	Badge	What it means
detected	read from your code	Read literally off a manifest or the file index. A fact.
inferred	inferred — confirm it	A pattern generalised into a claim. It waits for a person.
stated	you wrote this	Something only a human knows.

And a status: proposed, confirmed or rejected.

Only confirmed rows reach an agent. That is the whole discipline. Without it, Madebook would enforce whatever the codebase happened to do most often, including its mistakes.

A rejected row is kept, not deleted — so the same inference is not proposed again the next time the repository is indexed.

Every item also carries a confidence figure from 0 to 100, and where relevant the evidence path that produced it.

What it holds

Five pieces of prose

Field	What belongs in it	Weight
What this product does	Business context.	25
Business constraints	Domain rules, terminology, and the limits the code cannot reveal.	35
Architecture	The shape of the system.	20
Data flow	How data moves.	14
Local setup	How to run it.	6

The weights are the completeness score. A field counts as answered at 40 characters or more. The five prose weights plus three list weights are divided by 120 to give the percentage.

Business context and business constraints are never written by any automated pass. They are yours.

Five lists

Technologies — name, category (language, framework, database, cloud, identity, messaging, tooling), version, notes, plus the provenance above. Up to 60.

Standards — the team's engineering rules. Each has a category (naming, branching, pull_request, testing, error_handling, logging, documentation, performance, accessibility, deployment, other), a title, a detail, an example, and a strength: must, should or may. Up to 60.

Security rules — title, detail, category (secrets, authentication, authorization, data_handling, network, dependencies, logging), and an enforcement of mandatory or recommended. Up to 40.

These have no provenance columns. Security rules are always human-stated, and they are the last thing in the brain section of a brief — the position a model weights most.

A security rule can also be marked as blocking external AI, which constrains what Madebook itself may send to a provider.

Organization preferences — title and detail. Not rules: an engineer who does not know it wastes a week. Up to 40.

Known problems — title, detail, area, severity (low, medium, high, critical), location, and a status of open, mitigated or resolved. Up to 60. These hang off the workspace rather than the context record, because problems outlive a context rewrite. Only open problems reach a brief.

Reading it out of the repository

Read my repository runs two passes and shows you the result before anything is enforced.

Pass one: deterministic, no model at all

57 technology signatures are matched against your dependency names — as a whole name, or as a namespace prefix. Confidence is 95 for a direct dependency and 60 for a transitive one. Even a direct dependency is not 100: the package can be present and unused.

Languages come from the file index. A language in fewer than 5% of indexed files is ignored — a language in one file out of four hundred is a script, not the stack. Above 25% share it is scored 95, otherwise 75.

Inferred standards, each at a fixed confidence: a test runner (70), Prettier or ESLint (70), TypeScript (75), Zod (65), a layering convention (55, and only when at least two controller-shaped and two service-shaped files exist), and a test command (80).

Local setup is built from your manifest's scripts, preferring dev, start, build, test, lint, migrate, seed and reset, otherwise the first six. Confidence 90, source detected.

The rule the whole pass follows: no evidence, no item.

Pass two: the model drafts prose

Only architecture_overview, data_flow and business_context — and this pass is given structure only, never file contents, which keeps it clear of your source-retention setting entirely.

Everything it returns is stamped inferred, and its confidence is capped at 85 whatever it claimed. It will not draft business constraints at all.

With no provider configured, you get the deterministic half and an honest note:

No AI provider is configured, so this is the deterministic draft only: the stack read from the manifests. What the product does, the domain terminology and the data flow were left empty rather than invented.

What the read writes

• Technologies land confirmed. Skipped if one with the same name already exists.
• Standards land proposed. Skipped on a duplicate title. Nothing proposed reaches a brief until a person confirms it.
• Prose is written only into architecture, data flow and local setup, and only where the field is currently empty. A person's correction is never overwritten.
• Where the two passes disagree, the deterministic result wins.

Two things stop a read before it starts:

• "No repository is connected to this workspace yet."
• "The repository has not been indexed yet — press Re-index on the Repositories page, then read it again."

Field suggestions

Four fields — the workspace description, the business objective, business context and business constraints — carry a Suggest button.

It drafts from a knowledge document Madebook keeps per organization: distilled from the organization's name, industry, description and website, plus every workspace's mission, objective, description and context prose. The website is fetched with a 15-second timeout; the homepage and up to three linked pages are read.

You get two genuinely different candidates, each under about 100 words. Click one to use it, then edit it freely.

The widget is honest about what it is working from:

• First build: "Knowledge built just now from your website and data — click one to use it."
• Later: "Drafted from what Madebook knows about your organization — click one to use it, then edit freely."
• Stale: "Your data has changed since this knowledge was built — these suggestions may be behind." with a Reindex and regenerate link.

With no provider:

No AI provider is configured, so there is nothing to suggest from.

The drafting is a background job, not something the page waits on. Press Suggest, go to another page, come back — the box reads "Drafting from what Madebook knows about your organization — you can leave this page; the drafts will be here when you come back" while the job runs, and the drafts are there when it is done. They stay until you click one or close the box. Reload the page and the same box reopens with whatever the job has by then. The request is a row Madebook keeps (one per field, until dismissed), and AI jobs run on three parallel lanes, so a suggestion does not wait behind a long repository analysis.

History

Every save writes a revision with a summary and a field-by-field before and after. This is the one place in Madebook where the same content lives twice on purpose.

Note that every child row is rewritten on each save, so a row's identity does not survive an edit. "When was this problem first recorded" is not a question the data can answer.

Related

• The brief — where all of this ends up.
• Architecture rules — a different, stricter thing.
• Codebase intelligence