Skip to main content
Glama

aiworkhub_manager_learning_commit

Persist a verified Learning Commit for an accepted or rejected task decision, auto-resolving evidence and provenance, then promote lessons, invariants, or Context Graph edges when needed.

Instructions

MANAGER WRITE: persist and project one verified Learning Commit.

SHORT FORM -- the one to use: task_id, request_id and the lesson. Everything mechanical is resolved server-side from the card's OWN decision event: outcome is read from the adjudication (never asserted), repo_area from the paths that decision was taken over, evidence_ids from the sealed FIXED_AND_VERIFIED acceptance reference, and idempotency_key/provenance are the deterministic strings the learning_commit_owed payload in your accept/reject reply already carried. failure_category is always derived server-side from the card's structured terminal evidence and is never caller-suppliable. repo_area omitted is derived from the decision's paths; any explicitly supplied value is normalized and honored, while an empty or whitespace value is refused with learning_commit_repo_area_invalid:empty.

Add your own references with extra_evidence_ids. An evidence id must carry an allowed scheme -- file:, http: or https:. A sha256: receipt id is refused, and any refusal here returns allowed_evidence_id_schemes.

outcome is accepted, rejected or inconclusive; only the first two may promote, and each promotion needs what its store demands (a lesson for AI Memory, an invariant for KB, an edge plus an acceptance for Context Graph).

LONG FORM (compatibility): supply repo_area, outcome, evidence_ids, idempotency_key and provenance yourself and nothing is resolved. The lesson text is always the caller's; nothing is written without this call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_id": "<task_id>",
      "request_id": "<request_id>"
    },
    "name": "aiworkhub_manager_learning_commit"
  }
}

Input Schema

NameRequiredDescriptionDefault
outcomeNoaccepted, rejected or inconclusive; omit to read it from the card's own adjudication. Only accepted and rejected may promote.
task_idYesId of the card whose accepted or rejected decision this learning commit records.
repo_areaNoRepository-relative area the lesson concerns, at most 256 bytes with no absolute path, .., backslash or colon; omit to derive it from the decision's paths.
promote_kbNoTrue also promotes the invariant to the KB; needs outcome accepted or rejected, an invariant_candidate and an evidence id. Default false.
provenanceNoNon-blank provenance text recorded with the commit, at most 2048 bytes; omit to use the deterministic string from the learning_commit_owed payload.
request_idYesId of the judged worker request, as carried by the learning_commit_owed payload of the accept/reject reply.
evidence_idsNoEvidence ids, each starting with file:, http: or https: (a sha256: receipt id is refused); omit to resolve them from the card's sealed acceptance reference.
edge_candidatesNoContext Graph edges to propose, each an object with string keys source, target (different, at most 256 each) and relation (at most 64); promote_context_graph needs one.
idempotency_keyNo8-192 characters matching ^[A-Za-z0-9][A-Za-z0-9_.:-]{7,191}$; omit to use the deterministic key from the learning_commit_owed payload.
lesson_candidateNoLesson text to record with the commit; promote_ai_memory needs it. Default empty.
promote_ai_memoryNoTrue also promotes the lesson to AI Memory; needs outcome accepted or rejected, a lesson_candidate and an evidence id. Default false.
extra_evidence_idsNoFurther evidence ids merged into the resolved or supplied evidence_ids, with the same allowed schemes; default none.
invariant_candidateNoCandidate invariant to record with the commit; promote_kb needs it. Default empty.
root_cause_candidateNoCandidate root cause to record with the commit; default empty.
promote_context_graphNoTrue also promotes edge_candidates to the Context Graph; needs outcome accepted and an evidence id. Default false.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv0.12.67
    • addedInput schema / properties / edge_candidates / description
      Added value: +"Context Graph edges to propose, each an object with string keys source, target (different, at most 256 each) and relation (at most 64); promote_context_graph needs one."
    • addedInput schema / properties / evidence_ids / description
      Added value: +"Evidence ids, each starting with file:, http: or https: (a sha256: receipt id is refused); omit to resolve them from the card's sealed acceptance reference."
    • addedInput schema / properties / extra_evidence_ids / description
      Added value: +"Further evidence ids merged into the resolved or supplied evidence_ids, with the same allowed schemes; default none."
    • addedInput schema / properties / idempotency_key / description
      Added value: +"8-192 characters matching ^[A-Za-z0-9][A-Za-z0-9_.:-]{7,191}$; omit to use the deterministic key from the learning_commit_owed payload."
    • addedInput schema / properties / invariant_candidate / description
      Added value: +"Candidate invariant to record with the commit; promote_kb needs it. Default empty."
    • addedInput schema / properties / lesson_candidate / description
      Added value: +"Lesson text to record with the commit; promote_ai_memory needs it. Default empty."
    • addedInput schema / properties / outcome / description
      Added value: +"accepted, rejected or inconclusive; omit to read it from the card's own adjudication. Only accepted and rejected may promote."
    • addedInput schema / properties / promote_ai_memory / description
      Added value: +"True also promotes the lesson to AI Memory; needs outcome accepted or rejected, a lesson_candidate and an evidence id. Default false."
    • addedInput schema / properties / promote_context_graph / description
      Added value: +"True also promotes edge_candidates to the Context Graph; needs outcome accepted and an evidence id. Default false."
    • addedInput schema / properties / promote_kb / description
      Added value: +"True also promotes the invariant to the KB; needs outcome accepted or rejected, an invariant_candidate and an evidence id. Default false."
    • addedInput schema / properties / provenance / description
      Added value: +"Non-blank provenance text recorded with the commit, at most 2048 bytes; omit to use the deterministic string from the learning_commit_owed payload."
    • addedInput schema / properties / repo_area / description
      Added value: +"Repository-relative area the lesson concerns, at most 256 bytes with no absolute path, .., backslash or colon; omit to derive it from the decision's paths."
    • addedInput schema / properties / request_id / description
      Added value: +"Id of the judged worker request, as carried by the learning_commit_owed payload of the accept/reject reply."
    • addedInput schema / properties / root_cause_candidate / description
      Added value: +"Candidate root cause to record with the commit; default empty."
    • addedInput schema / properties / task_id / description
      Added value: +"Id of the card whose accepted or rejected decision this learning commit records."
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare a non-readonly, non-destructive, closed-world write. The description adds substantial behavior: server-side derivation of outcome/repo_area/evidence_ids/idempotency_key, refusal behavior for invalid repo_area, evidence scheme enforcement, promotion prerequisites, and idempotency guarantees.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the primary short-form path and relegates long form to compatibility, but it is verbose and somewhat repetitive in its validation details. Still, every section serves the complex 15-parameter operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values need not be explained. The description covers write semantics, promotion prerequisites, parameter resolution, and error behavior sufficiently for a complex 15-parameter mutation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds crucial operational meaning beyond the schema: which parameters to omit in short form, how omitted values are resolved server-side, explicit evidence schemes, and the repo_area normalization/refusal rule.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'persist and project one verified Learning Commit.' This clearly distinguishes it from sibling manager read/search tools and from generic write tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly labels the short form as 'the one to use' and long form as compatibility, and states that nothing is written without this call. The agent knows both the preferred invocation path and the mandatory nature of the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools