@c4a/context-cli 0.7.9 → 0.7.10-alpha.2

package/indexers/bundles/context-code-indexer/references/indexer.md

@@ -1,328 +1,137 @@
-# Code Indexer authoring contract
-
-Consume only the current workset authority and the single Authorized Workset View supplied by Context. Normalized parser facts, verified layer fragments, document evidence, and tool observations all arrive through that View; do not open source-specific evidence channels or manage their pagination and receipts.
-
-Use the bound requirement's `purpose` and open `reader_goals` to identify the
-reader's task. Integration guides prioritize imports, normal use, interfaces
-and relevant limitations. Maintenance guides retain implementation handoffs,
-identity and field transformations, actual failure handling, state and success
-conditions when these serve the requested task. Judge coverage by
-whether supported profile questions and stable capability boundaries are
-actually explained, never by symbol, file, relation, or evidence counts.
-
-## Classify before selecting templates
-
-Classify each requested module from current manifests, stable entries, public contracts, runtime registration, maintained documentation, and source-backed boundary evidence. Select one primary profile and only the additional profiles supplied by the current workset. A directory name, framework dependency, class suffix, or generated file is not sufficient classification evidence.
-
-Read only the templates materialized for the selected profiles. Combine their questions into one deduplicated plan for the reader-visible capability; a template is guidance, not a source of facts, page counts, output paths, thresholds, or authority. Keep a repository container, public contract, runtime boundary, event flow, persistence boundary, adapter, generated-source provenance, and cross-module handoff separate when they answer different reader questions. Do not copy a template outline when source evidence does not support its sections.
-
-Partition selects permitted intents and templates from the current Provider
-catalog. A topic may contain several articles with distinct reader tasks and
-stable keys; members still have one primary owner. Use the applicable article
-catalog to select complementary articles, not every available type. Save the
-reader task, article outlines, priority and natural delivery boundary. Author
-reuses that accepted plan and receives only its selected writing blueprints. A selected page
-program renders declared API fields from current Facts in the same Artifact as
-the semantic prose. Do not transcribe its table or manufacture missing defaults.
-Optional `template_variables` supply only the program's declared semantic slots;
-write the remaining supported guidance as normal Sections.
-
-For websites, organize around page tasks and data boundaries; distinguish host
-and remote declarations from verified loading behavior. For services and BFFs,
-identify actual inbound registration or IDL before describing a remote API;
-an outbound client is not a server. For events and scheduled tasks, explain the
-registered trigger and source-confirmed completion, retry and failure behavior.
-No dedicated behavior Fact is required when authorized captured source answers
-the question. Ask for additional material only when that source is insufficient
-for the core reader task; do not block other complete pages on local uncertainty.
-
-Reuse accepted plans and Results across deliveries. Follow the current theme
-wave and page batch selected by Context through Review, close and build. A theme
-can span several page batches; continue its remaining articles after build.
-A readable first batch does not mean the whole source is finished.
-
-## Partition and identity
-
-Use the complete scope/member overview first; inspect linked fact details and
-captured source only where necessary to resolve a theme. Check public entrypoints,
-shared types, wrappers and lifecycle boundaries before setting `ready_for_author`.
-Do not infer a whole repository from samples or automatically exclude internal,
-generated or deprecated paths. Every supplied member still needs a disposition.
-A ready theme may be written and delivered while other themes remain in planning.
-Preserve the accepted subject when subsequent material supplements it; start from
-its approved prose and retain unaffected content. Source details deferred during
-planning must be examined before corresponding behavior claims in Author.
-
-
-Public API coverage does not imply one page per exported symbol. Group simple
-helpers, related types and aliases under their caller-facing capability while
-retaining useful inputs, outputs and edge cases. Give an API its own page when
-it has an independent integration contract or reader task. Tests, fixtures and
-stories support those contracts; they are not reader targets merely because
-they are present in the inventory.
-
-Same names from different public entrypoints or incompatible current/deprecated
-contracts are different subjects. Qualify their semantic subject and title by
-entrypoint or lifecycle; do not merge them by name or let a legacy title describe
-a current API. An explicit migration/comparison page may relate both, but must
-explain which contract belongs to each entrypoint. Preserve already accepted
-subjects during continuation; do not repartition them for cosmetic grouping.
-For retained deprecated components, use the optional guidance in
-[the component-library profile](../templates/component-library.md#optional-guidance-for-deprecated-components).
-It guides source-backed differences, not mandatory columns or automatic migration advice.
-
-Actively assess useful coverage from available public entrypoints, maintained
-guidance, explicit lifecycle notices and representative source material. Identify
-what answers the reader's task, what is needed only to support it, and what may
-be outside it. This applies to code of any age: deprecated APIs can be essential
-for existing users, while current code may be irrelevant to this task. A legacy
-directory, generated file or test is a clue, not an automatic exclusion; examples,
-tests and generated contracts can contain necessary usage or interface facts.
-
-When a material new scope choice appears, explain the concrete region, available
-counting basis, recommendation and coverage consequences to the user before
-writing dependent pages. Unnecessary regions consume tokens and preparation,
-writing and review time, and can obscure useful guidance with duplicate or
-conflicting content. Do not trade required coverage for speed, invent savings,
-scan the whole repository just to count, or treat worksets as component/page counts.
-Follow Context's existing conversational scope clarification even in managed mode;
-reuse explicit decisions and do not invent a scope-confirmation Gate. Apply agreed
-member dispositions through the current Result; do not silently narrow scope,
-remove accepted pages or restart unrelated work. If lifecycle relevance is not yet
-checked, report that limitation rather than asserting there is no obsolete content.
-
-For partition work, close every inventory member as owned, excluded, or unsupported and use stable semantic subjects. Each member has exactly one primary owner; extension layers may enrich but cannot claim final authority. Do not create ordinal batches or infer identity from display titles, filenames, headings, or traversal order. If no defensible semantic grouping exists, return the protocol failure that permits the CLI-owned catalog fallback.
-
-Apply the grouping principles below and the selected-profile guidance already
-present in `resolved-indexer-instructions` to the current View. Context owns
-strategy selection, ordering, retry, and catalog fallback; strategy identifiers
-and digests are internal bookkeeping, not additional material to retrieve or
-fields to submit. Return semantic groups and member dispositions only within
-the supplied inventory and subject contract.
-
-Group related identities by a capability, entrypoint, protocol boundary, lifecycle stage, state owner, or handoff. A granular catalog is appropriate only when the selected profile and reader goal require a public API, protocol, command, or registry reference. A cross-module chain requires an explicit trigger, source-backed joins on both sides of every boundary, transformations or state handoffs, and a terminal outcome; imports or similar names do not prove execution order.
-
-A module-level overview may be one logical unit, but it must not own every
-member of a large application or service when current facts expose stable route
-families, public capability families, protocol surfaces, runtime workers, or
-storage boundaries. Give those boundaries separate semantic groups and keep the
-overview limited to navigation and shared lifecycle. This keeps each Author View
-bounded enough to inspect and prevents a catch-all page from replacing useful
-knowledge. Never split by traversal order, member count, or numbered batches.
-Renaming a fact-kind bucket such as all relations or all symbols is not semantic
-partitioning; assign cross-boundary facts to the smallest capability, protocol,
-runtime, or state boundary that they actually explain.
-
-Create a reader target only from a CLI-supplied declaration, public export, contract declaration, runtime registration, approved Subject, or Partition Subject identity. Import/re-export aliases, ordinary references, internal helpers, and lightweight evidence may enrich their canonical owner but cannot independently authorize a target. Normalize aliases into the supplied canonical identity. Never promote a name merely because it appears in prose or has many inbound references.
-
-## Durable identity and reader-output boundary
-
-Keep durable locator identities compact and semantic. A locator may contain a
-normalized file coordinate, declaration identity, relation kind, line and a
-content digest, but never a raw call expression, implementation body, complete
-configuration value, remote response, secret, token, or credential-like source
-text. Full source material belongs only in the bounded process-local Fact payload;
-reader prose consumes its verified meaning, not the internal carrier.
-
-The selected profile templates are mandatory authoring guidance. Use current
-facts to answer their reader questions about responsibility, entrypoints,
-contracts, state, handoffs, failure behavior, configuration and operation. Omit
-unsupported sections. Do not replace those answers with a generic introduction,
-an exhaustive or representative symbol/path list, Parser/Indexer ownership text,
-selected-Fact counts, View/receipt/digest metadata, or claims about what the
-pipeline did. Those details neither help a reader nor recover production state.
-
-State caller-visible contracts directly when current facts support them:
-required inputs, defaults, quantity or size limits, and asymmetric rules between
-operations or variants. Naming an internal validator, mapper, hook, or generic
-"validation" step does not explain the contract. Omit details that current facts
-cannot prove rather than inferring them from an implementation name.
-
-## Declaration, implementation and test boundaries
-
-Distinguish the declared API from the implementation reached through the actual
-entrypoint. Inherited properties, comments and names do not prove forwarding,
-defaults or behavior. Tests support only what their assertions and non-mocked
-dependencies exercise; DOM presence alone does not prove visibility, focus or
-accessibility. Separate source-confirmed behavior from runtime hypotheses that
-need execution, and keep different platforms and deprecated entrypoints distinct.
-
-Knowledge production is not an exhaustive defect audit. Explain a discovered
-limitation when it changes how the reader calls, integrates or migrates the
-capability; retain the normal usage and responsibility as the page's focus.
-Request missing material only when it is needed for that reader task. A supported
-implementation limitation is useful knowledge, not a Context tool failure or a
-reason to pause the workflow. Do not expand into browser testing, source fixes
-or a separate issue per suspected defect unless that work was requested.
-
-## Author Result and evidence
-
-For author work, produce exactly one Result for the supplied logical unit. Keep deterministic catalogs separate from explanatory prose, bind every declaration and Section to current evidence, and select only an Artifact policy variant listed in the workset. Missing material must become a canonical question disposition; never invent an answer or emit placeholder knowledge.
-
-Before authoring, identify the concrete selected-profile question that the
-logical unit answers. Formal question refs are used only when the workset
-authorizes them, but their absence does not permit generic prose: do not turn the
-Partition Subject, group label, or available Fact volume into an implied reader
-purpose. Close the group as catalog-only when no profile question applies, or
-return to requirement/registry planning when required coverage lacks authority.
-
-An inventory group with no reader-authorizing public export, contract, runtime registration, approved Subject, or Partition Subject is catalog-only. Close its inventory dispositions and return no reader Artifact; do not publish a page that merely says the unit exists. Conversely, when the workset supplies current contract facts such as public signatures, properties, events, defaults, variants, examples, or source roles, consume each applicable fact in the matching template question or give it an explicit legal disposition. A generic directory summary is not a substitute for supplied contract facts.
-
-Select `artifact_intent` from the current Author authority's allowed tuples. Context applies that tuple to the published sections and resolves the collection; do not submit per-section layout metadata or invent a collection name.
-
-When the same Authorized Workset View contains CLI-authorized captured documents or tool snapshots, treat them as ordinary input evidence for the current logical unit. Use that material to answer a supplied question only when its evidence contract permits; otherwise keep the canonical material-gap disposition. Do not create a second answer flow or inspect registered sources outside the View.
-
-Treat the CLI inventory as the complete denominator, not a sample. Parser facts may prove files, declarations, entries, contracts, relationships and written default expressions; they do not by themselves prove business meaning, evaluated runtime values, failure behavior, or ownership. Every relationship must cite the concrete evidence for its own handoff. Do not repeat one whole-page evidence set across unrelated facts, and do not reduce a multi-source fact to one arbitrary primary file.
-
-With a program-generated API table, let its bound facts supply the field rows,
-types and defaults. Author prose explains when to use the API, how to combine it,
-and relevant pitfalls or migration limits. Refer to individual parameters when
-needed for that explanation; do not duplicate the table or narrate every row.
-An incorrect generated value needs a field-specific source reference and the
-current repair flow, not a contradictory prose override. This does not remove
-fact coverage or source verification, and does not apply to APIs for which the
-selected template provides no suitable program block.
-
-For generated API content, separate the displayed API from the facts supporting
-it. Keep relevant implementation or inherited-type facts as supporting material
-even when they need no separate page; use the current catalog/section references,
-not an exclusion to suppress duplicate presentation. Establish associations from
-declared links, not matching names. Shared types can have different defaults for
-different callers. A written `resolveDefault()` is an expression, not its evaluated
-result; an unresolved import does not prove an empty API. Read available captured
-source when the reader's task requires more certainty. Request material only if
-it is absent; report an extraction or rendering discrepancy when the source is
-already available. Preserve supported content and explain the specific limit.
-
-Inventory closure is not a license to attach a convenient fallback binding to
-unrelated members. A `boundary-only` member still needs evidence that places
-that member in the current semantic boundary; otherwise use the legal catalog,
-exclusion, unsupported, or material-gap disposition that describes its actual
-state. Denominator completeness with false attribution is invalid.
-
-Before declaring a dependency or handoff unverified, inspect the complete authorized
-source identity inventory for `code-relation` members and join their caller/callee
-identity to the supplied source spans. Relationship members can enrich a logical
-unit even when they are not primary partition members and do not need to be copied
-into the Result fact inventory. A large relation inventory is not evidence absence:
-select the few relations that cross a stable module, protocol, runtime, store, or
-generated-client boundary, then explain that boundary from the corresponding code
-span. Request material only when those authorized relations and spans still cannot
-establish the handoff.
-
-Close every CLI-supplied example candidate with exactly one decision: link it to its public target, merge it into a canonical example for the same target and scenario, retain it as a documentation example, exclude it with a reason, or request missing material. A retained representative must decide setup, key calls, parameters, and expected behavior as either extracted facts or evidence-backed not-applicable facets. Merge only by the full example identity supplied by Context; filenames and basenames are not identities. Do not omit an unresolved candidate from the decision set, and do not treat a material request as completed linkage.
-
-Explain stable responsibility, inputs, outputs, state and failure boundaries, the next handoff, and the evidence that supports each claim. Keep implementation bodies, generated payloads, exhaustive internal helper lists, and normalized template repetition out of reader prose. Empty Results are valid only when every target receives a legal disposition.
-
-## Post-author composer result
-
-For a post-author workset, use only the effective composer named by Context and the matching composer instruction materialized beside this contract. Consume the complete workset-scoped `PrimaryResultView`; do not reopen discovery, expand scope, change Subject identity or ownership, or return another complete main Result. A composer may emit only the declared `derived-artifact-proposal` kind and Artifact policy.
-
-If a declared primary fact or Artifact requirement is absent, or the view does not support an independent reader question, return the current task's semantic result with `stage: post-author`, `outcome: complete`, `proposals: []`, and `diagnostics: []` in the usual `results[]` envelope. Context constructs internal fragments and digests. Do not inspect temporary files or infer missing content.
-
-## Mechanical audit and revision
-
-Context independently validates production invariants it can derive from current
-inputs, including inventory and owner closure, parser coverage, Artifact
-completeness, source scope, identity, layout, and currentness. These failures
-block the current Result and must be fixed at their source.
-
-Profile metrics are authoring guidance, not a second readiness protocol. Use
-`references/metrics.md` when the Result exhibits a real reader problem, but do
-not alter wording, Markdown syntax, sentence counts, or partitions merely to
-influence a counter. Context does not accept an Agent-supplied score as proof
-that a Result is ready.
-
-Context does not judge prose quality or scan wording, JSX, comments or template
-syntax for rejection. Unfilled authoring placeholders can be noted during the
-existing content Review, but do not create a CLI failure or another gate. Do not
-rewrite a legitimate explanation solely to remove a marker or advisory.
-
-## Two classes of evidence in a template Evidence pass
-
-A template Evidence pass lists what to locate. Those entries do not all resolve the same way, and the difference decides whether an assertion can be written at all.
-
-The parsers name structural identity and declarative contracts: files and symbols, imports and call relations, configuration values, source spans, page and redirect routes, workspace and release units, protocol services, methods and types, contract endpoints and operations, maintained examples and public target links, stylesheet modifiers, tables, views and indexes, and generated-source boundaries. When an Evidence pass entry falls in this set, a fact carries it and the assertion binds to that fact.
-
-Nothing in the parser layer is named for operational behavior. There is no fact for a retry, a timeout, a lifecycle transition, a permission, a schedule, a topic or queue identity, idempotency, concurrency, ordering, a cache, a transaction, observability, a CLI command or flag, an exit code, or a component prop, slot, or variant. Templates still ask you to locate these, because they are what the reader needs — but they resolve only through a configuration value, a source span, or a relation that literally states them.
-
-So for this second class: base the assertion on the configuration value or
-source span that states the behavior, and name the identity it uses. If nothing
-in the authorized view states it, the behavior is a material gap. Write the
-gap. Do not convert a library dependency, a symbol name, or a familiar
-framework convention into a behavioral claim. Context validates structured
-references, but final Review remains responsible for rejecting unsupported
-prose.
-
-Every profile template ends with a `Revise or stop when` condition. Stopping means recording the material gap that blocks the question — the evidence that is missing and what would resolve it — and never silently dropping the question from the Result. A template that tells you to stop when discovery is inferred is telling you not to guess, not to omit. Dropping the question satisfies no entry and fails question closure.
-
-The complete reader-question set and canonical inventory are production
-obligations rather than quality scores. A PartitionPlan must cover the current
-question set, dispositions must cover the inventory, and an answered question
-must satisfy its evidence contract. Natural-language sentences are not checked
-one by one by a metric engine; keep them grounded in the supplied material and
-use final Review to remove unsupported interpretation. Excluding inventory may
-close a disposition, but it does not manufacture an answer to a reader
-question.
-
-A required question with no authorized supporting material remains a material request and cannot be published. Repairable content feedback reopens the owning Author or Composer through the same `context revise` lifecycle. Context does not keep a profile retry ledger and does not provide a profile-risk override Gate.
-
-Do not return output paths, collection names, quality thresholds, pass/fail
-decisions, extra owners, ad hoc question contracts, or facts outside the
-supplied authority. Context validates deterministic structure, references,
-layout, freshness, reconciliation, and final Review independently.
-
-## Notes and conversation summaries as supporting material
-
-Use only the authorized excerpts or summaries and cite the material actually
-read. Distinguish quotations, paraphrases, confirmed decisions and proposals;
-write the explanation useful to the reader instead of copying the source.
-Use code for API definitions and implemented behavior; a conversation can
-explain the reasons behind them. A summary may record that participants reported an implementation or a passing
-test; attribute that report and retain its stated version and scope. Do not
-present it as independently verified in this task. Claims of direct validation
-need the actual relevant code, execution or test results in the authorized
-material. Discussion or a plan alone does not establish completion.
-
-Keep this Provider responsible for the existing page. If the host selects a
-Note/Sessions or business Provider extension, apply its supplied instructions
-to the same writing task. Do not load an unselected skill or create a second
-page solely because supporting material has a different source type. An
-independent reader task can use a dedicated Provider selected by the host.
-
-If the source is inaccurate, return the correction to the host source-input
-flow; do not edit it from the Indexer. If only the knowledge is misleading,
-revise the page from its approved text through Author/Review. Keep source
-associations in the source and page/section references in structure.yaml;
-do not add provenance fields to the knowledge header.
-
-## Source example candidates
-
-For source-grounded usage examples, submit the optional Author
-`example_candidates` collection using a stable `scenario_key` and one delivered
-`source_item` per file. Read the example before selecting it; story/demo names
-do not establish behavior or relevance. Keep full relative paths so examples
-from different directories do not collapse by basename. The host preserves
-source/version/evidence identity and can pass accepted candidates to the
-selected examples Composer. Explain setup, key calls, relevant arguments and
-expected behavior only where the supplied source supports them; a source
-example does not establish that it executed successfully.
-
-For multiple component articles in one library subject, select each article's
-own component, Props, handle and related nested-type facts. Do not bind the
-whole library inventory to every article: the deterministic API table uses the
-facts selected for that article, so broad bindings duplicate unrelated APIs.
-Keep library-wide inventory in the library entry and link to component details.
-The CLI validates the selected identities; the Agent decides their relevance.
-
-## Diagrams
-
-Use the materialized [diagram guidance](diagrams.md) when a diagram clarifies the reader task. This also applies to older templates, source diagrams and Composer summaries. Preserve source strength, version and external boundaries; diagram presence is not a completion requirement.
-
-## Existing source images and tables
-
-For authorized visual material, follow [source visual processing](visual-source-processing.md): preference, capability-aware conversion, accepted-result reuse and retention. Follow the workspace AGENTS.md for editable diagram style.
-
-## Reading selected article material
-
-Use the current task's combined writing brief: it includes selected article guidance, examples when supplied, and section/variable slots. Profile bindings can share one article Markdown source; do not open every binding or regenerate every listed article. Keep short collaboration notes and examples beside the relevant guidance instead of requesting separate files. Read extra source or full technical contracts only when this task needs them. The CLI applies executable contracts and evidence bindings; the Agent decides applicability, substance and useful diagrams. Reuse an already-read unchanged shared resource while it remains in context.
+# Investigate and explain code
+
+## Planning supplies a skeleton
+
+Use the confirmed purpose and authorized module boundary. The CLI's directory
+and file navigation is a starting point, not a semantic grouping or a complete
+feature inventory. Inspect relevant manifests, public entry files, registrations,
+maintained documentation or a few representative declarations to understand
+which kinds of reader topics the module can support.
+
+Technology-specific investigation may be direct Agent reading or a bounded
+helper from an available skill. A helper should expose feature names, counts
+and source locations, not implementation bodies or a full relationship graph.
+It must respect the selected directory, stop within its budget and distinguish
+a completed count from an observed subset and remaining scope. Do not install
+dependencies or run a full parser merely to learn whether a feature exists.
+
+Filename and directory counts are mechanical. Components, routes and handlers
+need the corresponding source convention or bounded analysis; do not relabel
+file counts as feature counts. A timeout or incomplete scan is remaining
+investigation, not an empty module or an exclusion decision.
+
+A directory name, class suffix or dependency alone does not establish runtime
+behavior. It can suggest where to investigate. Selective source reading during
+planning can resolve a topic boundary; detailed behavior belongs to writing.
+
+## Topics and module boundaries
+
+Several skills may examine different aspects of one module. Combine their
+findings without assigning a permanent primary owner. Work module by module
+unless the authorized reader task requires a cross-module article. No automatic
+cross-module synthesis is required merely because imports exist.
+
+Typical signals suggest reader questions, not mandatory pages:
+
+- public exports or component declarations: how to consume a capability;
+- inbound registrations or interface definitions: which operations are served;
+- event or scheduled registrations: what triggers work and how it completes;
+- storage interfaces: data ownership and transactional boundaries;
+- adapters and generated clients: contracts at an external handoff;
+- package and workspace entrypoints: responsibility and consumption boundaries.
+
+A skill may suggest recurring outlines for an observed feature family, while
+the Agent chooses meaningful grouping and exceptions. A component manual may
+need component-by-component reading during writing; that does not require
+component-by-component deep analysis during planning. Do not produce one page
+per symbol or one generic catch-all for a large module with distinct capabilities.
+
+Use existing article navigation when extending knowledge. Later documents can
+supply better business names and rationale; code paths are structural hints,
+not immutable topic names. Preserve stable article identity when the reader
+task is unchanged. Different platforms or deprecated entrypoints may need
+separate treatment even when names match.
+
+Submit article targets, reader questions, sources and batches with the current
+plan schema. Keep pending scope explicit when only part is investigated.
+Do not submit subject matrices, per-file dispositions or an exhaustive fact
+ledger. The first executable plan still waits for work-start report feedback.
+Within that confirmed scope, append or replace unfinished tasks through the
+returned action; accepted content needs a revision task.
+
+## Writing follows actual behavior
+
+Explain what the module is responsible for, when and how to enter it through
+stable interfaces, what it hands off, and the relevant state and failure
+boundaries. A directory summary or symbol list is not an explanation.
+An integration guide focuses on consumption; a maintenance guide may need
+internal transformations and recovery. Follow the actual reader purpose.
+
+Read the source that establishes the claim. An outbound client is not an
+inbound service; host and remote declarations do not prove loading behavior.
+An import or matching name does not prove an executed call chain. To explain a
+cross-module sequence, verify the trigger, joins, transformations and outcome
+on the relevant sides of each boundary.
+
+Distinguish declarations from reached implementation. Inherited properties,
+comments and names do not prove forwarding or defaults. A written default
+expression is not its evaluated value. An unresolved import is not proof of
+an empty API. Inspect relevant implementations or existing parser detail only
+where the task needs it; do not dump a full parser response into an article.
+
+Tests establish only what assertions and real dependencies exercise. DOM
+presence does not by itself prove visibility, focus or accessibility. Separate
+source-confirmed behavior from runtime hypotheses. Knowledge production does
+not authorize source fixes, browser testing or an exhaustive defect audit.
+Explain a relevant limitation without replacing the normal usage guide with
+a list of suspected defects.
+
+When a source-backed helper generates an API table, check its fields, types and
+defaults against the selected target. Do not attach a whole library inventory
+to every component or narrate every table row. Correct a wrong generated value
+at its source; do not contradict it silently in prose. No helper is required
+when direct source reading answers the task adequately.
+
+Use examples that demonstrate the target and scenario. Read setup, key calls,
+parameters and expected behavior; a demo filename does not prove those facts,
+and source examples do not prove execution succeeded. Keep full source paths
+for citations without inventing an example-decision ledger.
+
+## References, revisions and delivery
+
+Write complete new articles using the current Markdown and reference schema.
+For revisions, use the supplied base article and references and edit only
+affected sections when appropriate. Preserve still-valid examples, limitations
+and confirmed contributions. New explanatory context does not require
+repartitioning unchanged code.
+
+Each fragment uses actual source regions, at most three locations; the CLI
+computes content digests. Do not use fallback evidence from an unrelated
+member, fabricate a continuous span for unrelated locations, or include
+process identities, full source bodies or credentials in reader output.
+
+Put draft Markdown, references or edits, and the submission manifest in the
+designated temporary directory. The coordinator submits completed tasks or a
+subset through the returned action. Source or target changes use the CLI's
+recovery path; do not overwrite an accepted task or directly edit formal files.
+No ArtifactResult, profile tuple, question-reference contract or score is
+required in the new file submission.
+
+## Supporting material and presentation
+
+Code establishes implemented behavior; authorized notes or documents can
+explain business intent and rationale. Preserve the difference between a
+proposal, confirmation, implementation and reported verification. Change links
+are context, not evidence that a change merged or passed tests. Several
+selected skills may contribute to the same article without creating copies.
+
+If the source is wrong, use its authorized correction flow. If the article is
+misleading, revise the article. Useful older or generated code is not excluded
+merely by its location; a material scope change needs the applicable user
+decision. Missing essential evidence remains visible rather than becoming a
+generic claim or silently omitted responsibility.
+
+Use [diagram guidance](diagrams.md) or [source visual processing](visual-source-processing.md)
+when actual reader needs or supplied images justify them. Diagrams are not
+mandatory. Content quality belongs to the Agent and Review; do not optimize
+wording, headings or section counts to satisfy a metric.

package/indexers/bundles/context-code-indexer/references/metrics.md

@@ -182,7 +182,7 @@ content.
 ### Meaning
 
 A reader target requires a CLI-authorized declaration, registration, public
-contract, approved Subject, or Partition Subject identity.
+contract, approved article, or Partition article identity.
 
 ### Revise
 

package/indexers/bundles/context-code-indexer/templates/adapter-integration-maintenance-guide.md

@@ -17,8 +17,7 @@
       "id": "api",
       "type": "json",
       "content_layer": "deterministic-fact",
-      "required": false,
-      "evidence_required": true
+      "required": false
     }
   ],
   "deterministic_blocks": [
@@ -40,13 +39,6 @@
       "deterministic_block_ids": [
         "api-table"
       ],
-      "accepted_evidence_kinds": [
-        "code",
-        "contract",
-        "configuration",
-        "documentation"
-      ],
-      "minimum_evidence_items": 0,
       "on_missing": "omit",
       "deletion_condition": "Omit when no authorized structured contract is available."
     }

package/indexers/bundles/context-code-indexer/templates/adapter-integration-request-adaptation-guide.md

@@ -17,8 +17,7 @@
       "id": "api",
       "type": "json",
       "content_layer": "deterministic-fact",
-      "required": false,
-      "evidence_required": true
+      "required": false
     }
   ],
   "deterministic_blocks": [
@@ -40,13 +39,6 @@
       "deterministic_block_ids": [
         "api-table"
       ],
-      "accepted_evidence_kinds": [
-        "code",
-        "contract",
-        "configuration",
-        "documentation"
-      ],
-      "minimum_evidence_items": 0,
       "on_missing": "omit",
       "deletion_condition": "Omit when no authorized structured contract is available."
     }

package/indexers/bundles/context-code-indexer/templates/adapter-integration-usage-guide.md

@@ -17,8 +17,7 @@
       "id": "api",
       "type": "json",
       "content_layer": "deterministic-fact",
-      "required": false,
-      "evidence_required": true
+      "required": false
     }
   ],
   "deterministic_blocks": [
@@ -40,13 +39,6 @@
       "deterministic_block_ids": [
         "api-table"
       ],
-      "accepted_evidence_kinds": [
-        "code",
-        "contract",
-        "configuration",
-        "documentation"
-      ],
-      "minimum_evidence_items": 0,
       "on_missing": "omit",
       "deletion_condition": "Omit when no authorized structured contract is available."
     }

package/indexers/bundles/context-code-indexer/templates/api-service-maintenance-guide.md

@@ -17,8 +17,7 @@
       "id": "api",
       "type": "json",
       "content_layer": "deterministic-fact",
-      "required": false,
-      "evidence_required": true
+      "required": false
     }
   ],
   "deterministic_blocks": [
@@ -40,13 +39,6 @@
       "deterministic_block_ids": [
         "api-table"
       ],
-      "accepted_evidence_kinds": [
-        "code",
-        "contract",
-        "configuration",
-        "documentation"
-      ],
-      "minimum_evidence_items": 0,
       "on_missing": "omit",
       "deletion_condition": "Omit when no authorized structured contract is available."
     }