Knowledge Setup

3. Types

Define types only when the person asks or agrees. Ask what the team keeps several of and would want in a table. Suggest from what the project already discusses (module, technology, competitor, person are common); the team decides. A type for a single page is not a type.

• Reuse first. Match on id and display name in tracker_list_types. If the project already has a fitting type (for example a competitor type), use it.

• Define with tracker_define_type and schema. Keep it small: title plus two to four single-valued fields (select, string, boolean, user, date). Only single-valued fields show in a page header; multi-valued fields show only in tables. No labels, kind or qualifier fields.

  {
    "type": "technology",
    "displayName": "Technology",
    "displayNamePlural": "Technologies",
    "icon": "memory",
    "color": "#7c3aed",
    "modes": { "inline": true, "fullDocument": true },
    "idPrefix": "tech",
    "idFormat": "ulid",
    "fields": [
      { "name": "title", "type": "string", "required": true },
      { "name": "maturity", "type": "select", "options": [
        { "value": "ga", "label": "Generally available" },
        { "value": "beta", "label": "Beta" },
        { "value": "deprecated", "label": "Deprecated" }
      ] },
      { "name": "inStack", "type": "boolean" }
    ],
    "roles": { "title": "title" }
  }

• Subtypes set extends: <base type> and declare only what they add ({ "type": "library", "extends": "technology", "displayName": "Library", "displayNamePlural": "Libraries" }). A subtype's pages show in its base type's table and nest inside it in the tree.

• Existing types: never pass overwrite without the person's approval, and then keep every existing field and option. Never pass confirmDestructive on your own.

• Place each new type where the person wants it with moveSharedItem (kind: type, itemId = the type id, newParentFolderId = the parent page, or none for the top of the section). A subtype is not placed; it shows inside its base. Offer two or three sentences for the type's page saying what belongs in it.

4. Relations

Add a relation when the team links two of its types often and the link means one specific thing ("built on", "competes with"). Each one is a predicate with:

• id (kebab-case), label, and inverseLabel (how it reads from the other page; the same as label when direction: symmetric)
• subjectKinds: the types a link can be written on; objectKinds: the types it can point at. Use the project's type ids; subtypes are covered through extends.
• valueShape: entity and direction: directed or symmetric. No qualifiers.

Copy the shape from ../knowledge-graph/references/relations.yaml, renamed to the project's types, and send only new ids with tracker_define_type (predicates: [...]; it merges by id and keeps the rest). Do not add generic relations ("related to", "depends on"): a plain link says that already.

• An existing id with a different definition is a conflict: keep it and report it.
• Adding objectKinds to an existing predicate narrows it and counts as destructive. Propose it to the person; only with their approval pass confirmDestructive.
• Never send removePredicates.

Report

End with one line per step: section, earlier-model content found (types, labels file, guide entity), guide page (link and status), types (each: created, already present, conflict, or needs placing), relations (added, already present, conflicts), and what the person still has to do in Pages.