I0814 — Give the worker a bounded slice of knowledge, not the knowledge base

Add a knowledge section to `majordomus context`, selected deterministically from what the active task and issue already reference, capped by a profile toggle and an item limit, dropped before any immutable fact when the budget is short, and named under EXCLUDED whenever it is dropped or switched off.

DONE wave 5 · p1 · implementation profile · runs alone

Part of M003 — A session is a durable envelope, and knowledge is compiled from what is already canonical.

Objective

Why

A context builder that dumps an index has replaced a selection problem with a bigger one. The value is in choosing the few pointers a worker needs, from relationships that are already explicit, and in saying out loud what was left out.

Current state

context assembles nine sections in authority order with a fixed drop order and names every exclusion. Its profile toggles decide what is asked for.

Desired state

The profile carries a knowledge toggle and a maximum item count, both in the profile allowlist. The section lists pointers — id, kind, title and source path — for the current issue, its dependencies, the claims it names and the documents it references. It sits below every immutable fact in the drop order and above nothing that outranks it.

Scope

lib/context.sh
share/skeleton
share/allow/profile.txt
.majordomus/profiles
docs
test/cases

Out of scope

Any similarity-based selection
Rebuilding the index from context
Raising the existing line budget

Dependencies

I0811DONE Read-only knowledge lookup with an ordering that can be explained

What waits on this

I0815BLOCKED Say what is now true in the claims, the documentation and the worker instructions

Acceptance criteria

The section appears only when the profile asks for it, and its absence is named under EXCLUDED with the toggle that caused it
It is dropped before git, the task, the profile and open blockers under a tight budget, and the drop is named
Selection comes from explicit references only, and a case proves an unrelated document is not selected
A stale index makes the section report staleness rather than silently omit itself
The existing context case still passes unchanged

Validation

bash test/run.sh 3073_context_knowledge_slice
bash test/run.sh 23_context

Evidence required

context_bounded

Evidence

covers	type	command	result	at commit
context_bounded	test	test/run.sh 3073_context_knowledge_slice 23_context	2 ok on feature/context-knowledge-pointers over master d116266803 (2026-10-16): the KNOWLEDGE POINTERS section lists, in tier order and nothing else, the issue, its depends_on issues, its milestone, the claims that milestone declares and the nodes its scope names (a look-alike document, an undeclared claim, another milestone's issue are not selected); knowledge_max_items cuts it and counts the rest, never above context.max_list_items; context.knowledge false or unset is named under EXCLUDED with the toggle; under a tight budget it is dropped before git, task, profile and open questions and the drop names majordomus knowledge related; an issue record that left the version-control index or is gone prints a stale line and the section stays; context writes nothing. 23_context passes unchanged. In this repository the section adds 5 lines of a 300-line budget and ~1.7 s (only the issue, its dependencies, milestones, claims and scope paths are compiled).	44ad51e

Risk

The budget is already close to full on a rich task. If the knowledge section is added without measuring, it will be the section that always gets dropped, which is a feature nobody receives.

Timeline

started: 2026-10-16T08:10:20Z
verified: 2026-10-16T08:10:24Z
completed: 2026-10-16T08:10:32Z

Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.

Canonical record: .ai/repo/project/issues/I0814.yaml. Read it back with majordomus plan show I0814.