Expand description
Object model definitions for Git blobs, trees, commits, tags, and AI workflow objects.
This module is the storage-layer contract for git-internal.
Git-native objects (Blob, Tree, Commit, Tag) model repository
content, while the AI objects model immutable workflow history that
Libra orchestrates on top.
§How Libra should use this module
Libra should treat every AI object here as an immutable record:
- construct the object in memory,
- populate optional fields before persistence,
- persist it once,
- derive current state later from object history plus Libra projections.
Libra should not store scheduler state, selected heads, active UI focus, or query caches in these objects. Those belong to Libra’s own runtime and index layer.
AI workflow objects are split into three layers:
- Snapshot objects in
git-internalanswer “what was the stored fact at this revision?” - Event objects in
git-internalanswer “what happened later?” - Libra projections answer “what is the system’s current view?”
§Relationship Design Standard
Relationship fields follow a simple storage rule:
- Store the canonical ownership edge on the child object when the relationship is a historical fact.
- Low-frequency, strongly aggregated relationships that benefit from fast parent-to-children traversal may additionally keep a reverse convenience link.
- High-frequency, high-cardinality, event-stream relationships should remain single-directional to avoid turning parent objects into rewrite hotspots.
§Three-Layer Design
+------------------------------------------------------------------+
| Libra projection / runtime |
|------------------------------------------------------------------|
| thread heads / selected_plan_id / active_run / scheduler state |
| live context window / UI focus / query indexes |
+--------------------------------+---------------------------------+
|
v
+------------------------------------------------------------------+
| git-internal event objects |
|------------------------------------------------------------------|
| IntentEvent / TaskEvent / RunEvent / PlanStepEvent / RunUsage |
| ToolInvocation / Evidence / Decision / ContextFrame |
+--------------------------------+---------------------------------+
|
v
+------------------------------------------------------------------+
| git-internal snapshot objects |
|------------------------------------------------------------------|
| Intent / Plan / Task / Run / PatchSet / ContextSnapshot |
| Provenance |
+------------------------------------------------------------------+§Main Object Relationships
Snapshot layer
==============
Intent --parents----------------------------> Intent
Intent --analysis_context_frames-----------> ContextFrame
Plan --intent-----------------------------> Intent
Plan --context_frames---------------------> ContextFrame
Plan --parents----------------------------> Plan
Task --intent?----------------------------> Intent
Task --parent?----------------------------> Task
Task --origin_step_id?-------------------> PlanStep.step_id
Run --task-------------------------------> Task
Run --plan?------------------------------> Plan
Run --snapshot?--------------------------> ContextSnapshot
PatchSet --run----------------------------> Run
Provenance --run_id-------------------------> Run
Event layer
===========
IntentEvent --intent_id-------------------> Intent
IntentEvent --next_intent_id?-------------> Intent
ContextFrame --intent_id?------------------> Intent
TaskEvent --task_id---------------------> Task
RunEvent --run_id----------------------> Run
RunUsage --run_id----------------------> Run
PlanStepEvent --plan_id + step_id + run_id-> Plan / Run / PlanStep
ToolInvocation--run_id----------------------> Run
Evidence --run_id / patchset_id?-------> Run / PatchSet
Decision --run_id / chosen_patchset_id?> Run / PatchSet
ContextFrame --run_id? / plan_id? / step_id?> Run / Plan / PlanStep§Libra read / write pattern
A typical Libra call flow looks like this:
- write snapshot objects when a new immutable revision is defined
(
Intent,Plan,Task,Run,PatchSet,ContextSnapshot,Provenance); - append event objects as execution progresses
(
IntentEvent,TaskEvent,RunEvent,PlanStepEvent,RunUsage,ToolInvocation,Evidence,Decision,ContextFrame); - rebuild current state in Libra from those immutable objects plus
its own
Thread,Scheduler,UI, andQuery Indexprojections.
§Object Relationship Summary
| From | Field | To | Cardinality |
|---|---|---|---|
| Intent | parents | Intent | 0..N |
| Intent | analysis_context_frames | ContextFrame | 0..N |
| Plan | intent | Intent | 1 canonical |
| Plan | parents | Plan | 0..N |
| Plan | context_frames | ContextFrame | 0..N |
| Task | parent | Task | 0..1 |
| Task | intent | Intent | 0..1 |
| Task | origin_step_id | PlanStep.step_id | 0..1 |
| Task | dependencies | Task | 0..N |
| Run | task | Task | 1 |
| Run | plan | Plan | 0..1 |
| Run | snapshot | ContextSnapshot | 0..1 |
| PatchSet | run | Run | 1 |
| Provenance | run_id | Run | 1 |
| IntentEvent | intent_id | Intent | 1 |
| IntentEvent | next_intent_id | Intent | 0..1 recommended follow-up |
| ContextFrame | intent_id | Intent | 0..1 |
| TaskEvent | task_id | Task | 1 |
| RunEvent | run_id | Run | 1 |
| RunUsage | run_id | Run | 1 |
| PlanStepEvent | plan_id | Plan | 1 |
| PlanStepEvent | step_id | PlanStep.step_id | 1 |
| PlanStepEvent | run_id | Run | 1 |
| ToolInvocation | run_id | Run | 1 |
| Evidence | run_id | Run | 1 |
| Evidence | patchset_id | PatchSet | 0..1 |
| Decision | run_id | Run | 1 |
| Decision | chosen_patchset_id | PatchSet | 0..1 |
| ContextFrame | run_id | Run | 0..1 |
| ContextFrame | plan_id | Plan | 0..1 |
| ContextFrame | step_id | PlanStep.step_id | 0..1 |
Modules§
- blob
- In Git, a blob (binary large object) is a type of Git object that stores the contents of a file. A blob object contains the binary data of a file, but does not contain any metadata such as the file name or permissions. The structure of a Git blob object is as follows:
- commit
- The Commit object is a data structure used to represent a specific version of a project’s files at a particular point in time. In Git, the commit object is a fundamental data structure that is used to track changes to a repository’s files over time. Whenever a developer makes changes to the files in a repository, they create a new commit object that records those changes.
- context
- AI Context Snapshot Definition
- context_
frame - Immutable context-frame event object.
- decision
- AI Decision Definition
- evidence
- AI Evidence Definition
- integrity
- Hash implementation for AI process objects.
- intent
- AI Intent snapshot.
- intent_
event - Intent lifecycle event.
- note
- Git Note object implementation
- patchset
- AI PatchSet snapshot.
- plan
- AI Plan snapshot.
- plan_
step_ event - Plan-step execution event.
- provenance
- AI Provenance snapshot.
- run
- AI Run snapshot.
- run_
event - Run lifecycle event.
- run_
usage - Run usage / cost event.
- signature
- In a Git commit, the author signature contains the name, email address, timestamp, and timezone of the person who authored the commit. This information is stored in a specific format, which consists of the following fields:
- tag
- In Git objects there are two types of tags: Lightweight tags and annotated tags.
- task
- AI Task snapshot.
- task_
event - Task lifecycle event.
- tool
- AI Tool Invocation Definition
- tree
- In Git, a tree object is used to represent the state of a directory at a specific point in time. It stores information about the files and directories within that directory, including their names, permissions, and the IDs of the objects that represent their contents.
- types
- Object type, actor, artifact, and header primitives.
- utils
- Low-level helpers shared by object encode/decode routines: varint readers, type/size parsing, and thin zlib compression wrappers tuned for Git object formats.
Traits§
- Object
Trait - The Object Trait Defines the common interface for all Git object types, including blobs, trees, commits, and tags.