DEV Community

canonical
canonical

Posted on

Task-Level Tools vs. Trajectory-Level Methodology: The Fundamental Divide Between Trellis, OpenSpec, and AGE

#ai #programming #agents #openspec

Introduction

Analysis

1. Positioning: What the Three Are

Trellis:

  • A productized engineering framework, installed via npm install -g @mindfoldhq/trellis && trellis init.
  • Provides a 3-phase workflow (Plan → Execute → Finish), task management scripts, a spec system, sub-agent dispatch, and multi-platform hooks.
  • The toolchain is determined at design time: 12 skills such as trellis-brainstorm, trellis-check, trellis-update-spec, trellis-break-loop, and so on.
  • 5 core principles: Plan before code, Specs injected not remembered, Persist everything, Incremental development, Capture learnings.

OpenSpec:

  • A productized spec-driven framework, installed via npm install -g @fission-ai/openspec && openspec init.
  • The core model is the spec + delta + archive cycle: specs/ (source of truth) ← merge ← changes/ (delta specs).
  • Each change contains four artifacts — proposal → specs → design → tasks — generated according to a schema dependency graph.
  • Delta specs use ADDED/MODIFIED/REMOVED to describe incremental modifications and are merged back into the main specs upon archive.
  • 4 philosophies: fluid not rigid, iterative not waterfall, easy not complex, brownfield-first.
  • Supports slash command integration for 25+ AI tools.

AGE:

  • A methodology, not a product. No npm package, no install command.
  • The AGE Template is a copy-and-use document skeleton (https://github.com/entropy-cloud/attractor-guided-engineering-template) that defines document responsibilities and processes, accompanied by generic tools (check-doc-links, check-oversized-files, etc.). Domain-specific tools need to be extracted from practice.
  • The AGE author has open-sourced several large-scale example projects demonstrating complete AGE practices in different domains:
  • Theoretical framework: state space → attractor → trajectory → control; all practice elements can be deduced from this.

2. Tool Origin: Preset vs. Gradually Emerged

Trellis has 12 built-in skills; AGE’s domain tools need to be accumulated by oneself, or borrowed from other projects.

Trellis: Tools Determined at Design Time

Trellis’s 12 skills exist at project creation:

Skill Origin Responsibility
trellis-brainstorm framework preset requirement discovery process
trellis-check framework preset code quality checks
trellis-update-spec framework preset spec write-back
trellis-break-loop framework preset deep bug analysis (5-dimension framework)
trellis-before-dev framework preset pre-development context loading
trellis-finish-work framework preset task wrap-up
trellis-start framework preset task initiation
trellis-continue framework preset task resumption
trellis-meta framework preset framework self-operation
first-principles-thinking framework preset thinking method
python-design framework preset Python design guide
contribute framework preset contribution guide (docs, marketplace)

These skills are generic and unrelated to any specific project. Users get these tools without needing a bug history or audit findings. Among them, trellis-break-loop and trellis-update-spec form a mechanism to extract knowledge from failures (see Section 3 for details).

AGE: Tools Extracted Gradually from Practice

The tool growth chain in nop-chaos-flux is clearly visible:

Chain 1: hardcoded type dispatch → audit script

Bug found: hardcoded type switch in the renderer
  → audit finding: violates the architectural contract "renderers should dispatch via registry"
  → Plan 430: eliminate-hardcoded-type-dispatch-plan
  → extracted as script: scripts/audit/find-hardcoded-type-dispatch.mjs
  → rules encoded in: scripts/audit/rules.mjs
Enter fullscreen mode Exit fullscreen mode

Chain 2: missing renderer markers → audit script

Bug found: renderer did not output marker class as per contract
  → appeared multiple times in deep audit dimension 09
  → extracted as script: scripts/audit/find-missing-renderer-markers.mjs
Enter fullscreen mode Exit fullscreen mode

Chains 3–5: imprecise reactive subscriptions, async without failure path, React 19 legacy APIs → each with a corresponding audit script.

nop-entropy follows the same pattern:

Bug found: bare RuntimeException used in Java code
  → convention: NopException subclasses should be used
  → extracted as ast-grep rule: ai-dev/tools/rules/java-lint-bare-runtimeexception.yml
Enter fullscreen mode Exit fullscreen mode

Out-of-the-Box vs. Gradual Accumulation

A new Trellis project instantly gets the complete 12 skills + workflow state machine + cross-platform hooks. A new AGE project starting from the Template has only generic tools, but can refer to open-source exemplars such as nop-chaos-flux, nop-entropy, and nop-chaos-next to quickly establish domain-specific tools. Trellis suits "starting today"; AGE suits "long-term evolution".

3. Extracting Knowledge from Failures: Two Mechanisms of Different Depth

Both Trellis and AGE extract knowledge from failures, but the artifact form and degree of automation differ.

Trellis: Extract to Prose Spec

trellis-break-loop provides a structured 5-dimension bug analysis framework:

  1. Root Cause Category: 5 categories (Missing Spec / Cross-Layer Contract / Change Propagation Failure / Test Coverage Gap / Implicit Assumption)
  2. Why Fixes Failed: 4 failure modes (Surface Fix / Incomplete Scope / Tool Limitation / Mental Model)
  3. Prevention Mechanisms: 6 mechanisms (Documentation / Architecture / Compile-time / Runtime / Test Coverage / Code Review)
  4. Systematic Expansion: similar issues / design flaws / process flaws
  5. Knowledge Capture: mandatory update of spec files ("The analysis is worthless if it stays in chat. The value is in the updated specs.")

After analysis, the knowledge is written into .trellis/spec/ via trellis-update-spec, precipitated as prose in forms like Design Decision, Common Mistake, Case Study, etc.

AGE: Extract to Gradually Automated Tools

AGE’s promotion ladder (AGE Template AGENTS.md Rule 15):

Level 0: discover repeated issues
  ↓
Level 1: bug note (docs/bugs/) — record non-obvious root causes
  ↓
Level 2: lesson (docs/lessons/) — extract reusable judgment rules
  ↓
Level 3: skill/prompt (docs/skills/) — reusable audit/diagnostic methods
  ↓
Level 4: audit script (scripts/audit/) — semi-automated scanning
  ↓
Level 5: lint rule / CI guard — fully automated interception
Enter fullscreen mode Exit fullscreen mode

nop-chaos-flux’s docs/skills/ directory (22 prompt files):

Skill/Prompt Promotion Source
bug-diagnosis-prompt.md (242 lines) diagnostic methodology extracted from 66+ bug fix histories
open-ended-adversarial-review-prompt.md (116 lines) open-ended discovery method extracted from multiple rounds of adversarial review
deep-audit-prompts.md (2141 lines, 20 dimensions) structured review framework extracted from multiple rounds of deep audits
implementation-contract-review-prompt.md contract review method extracted from plan closure audits

Core Differences

Both extract knowledge from failures, but the form and automation level of the artifacts differ:

Dimension Trellis AGE
analysis framework 5 dimensions (break-loop) promotion ladder (5 levels)
knowledge artifact prose spec (coding conventions, cases) prompt → script → lint rule (gradual automation)
deposit location .trellis/spec/ docs/skills/ → scripts/audit/ → CI
automation level prose only (human-readable) prose → semi-automated scanning → fully automated interception
escalation mechanism none (break-loop output goes directly into spec) yes (same pattern recurring promotes to higher level)

The reason AGE can escalate is that it has dedicated time-sensitive document categories (bugs/, lessons/, skills/) to track whether a pattern repeats. Trellis precipitates knowledge into the spec once; when the same mistake is made again there is no upgrade path.

4. Document Organization: Domain-Adapted vs. Framework-Adapted + Normative/Historical Separation

These are two closely intertwined dimensions: who determines the document structure, and whether normative and historical information are separated.

Trellis: Framework-Preset Fixed Structure, Normative and Historical Mixed 

.trellis/                  # top-level directory mandated by Trellis
├── spec/                  # coding conventions organized by package/layer + accumulated learnings
│   ├── cli/backend/
│   ├── cli/unit-test/
│   └── guides/
├── tasks/                 # task directories named by date (archived after completion)
│   └── MM-DD-name/
│       ├── prd.md / implement.jsonl / check.jsonl / task.json
└── workspace/             # session memory isolated by developer name (rotates at 2000 lines)
Enter fullscreen mode Exit fullscreen mode

This structure serves Trellis’s own operation: the layering of spec/ serves the discovery mechanism of get_context.py, the format of tasks/ serves the lifecycle management of task.py, and the developer isolation of workspace/ serves multi-user scenarios. The 5 core principles (Plan before code, Persist everything, etc.) are cross-project constraints.

Normative and historical are not separated. The template types of trellis-update-spec (Design Decision, Common Mistake, Case Study, Gotcha) naturally encourage writing historical information into the spec. trellis-break-loop also requires "update spec/guides" after the 5-dimension analysis. Trellis has no separate bugs/, logs/, or lessons/ directories — tasks/ are archived upon completion, and workspace/journal rotates at 2000 lines. Learnings have nowhere to go but into the spec.

A real example — historical content in quality-guidelines.md (982 lines):

  • "Case Study (2026-04-22): current_phase / next_action drift across 4 writers + type declaration" — a complete bug evolution history including "what the first audit missed," "four drift patterns," and "final integration result"
  • "Cautionary tale — 0.6.0-beta.3 → 0.6.0-beta.4 emergency revert" — account of a version rollback incident
  • "Case Study (2026-04-30): issue #204 --yes + bootstrap recovery" — includes commit hash, discovery process, and fix process

In workflow-state-contract.md (299 lines): "Two production bugs (Phase 1.3 jsonl curation skip, Phase 3.4 commit skip) hit exactly this failure mode."

Case Studies mixed into the spec provide immediate causal context ("why does this rule exist"), whereas AGE requires cross-file references to obtain the same context. The cost is spec file bloat and the AI’s inability to distinguish "current specification" from "historical lesson" when reading.

AGE: Organized by Domain Needs, Strict Normative-Historical Separation

AGE document organization has only two constraints:

  1. Progressive disclosure: unfold from a minimal entry point (index / start-here) gradually to detailed content.
  2. Separation of normative and time-sensitive history: stable files use stable names; time-sensitive records carry dates.

Within these constraints, each project organizes its document structure according to its domain needs.

nop-chaos-flux (frontend low-code framework): docs/architecture/ organized by 4-layer priority (programme → conventions → baseline → subsystems), docs/components/ has 100 component design docs, docs/references/ compresses the most-used types into a single file. This is the domain need of a frontend framework.

nop-entropy (backend full-stack framework): docs-for-ai/ organized by numbered prefix reading order (00→04), separated from ai-dev/ (development process memory). Because users and developers are completely different audiences.

AGE Template (application-layer projects): has input/ (raw PM input) separated from requirements/ (implementation-ready requirements), and backlog/ (priority queue). This is the domain need of application development.

AGE’s normative/historical separation is explicitly stipulated by nop-chaos-flux plan guide Rule 14:

Documents under docs/architecture/ only describe the latest current design state. Do not write historical changes, do not write "Proposed vs Current" comparisons, do not write evolution narratives.

Only three types of historically related content are allowed in normative documents: the reason for a choice (why A over B), rejected alternatives with reasons (negative space), and exception records ("intentionally retained legacy behavior"). Evolution narratives must stay in logs/, bugs/, plans/.

Core Differences

Dimension Trellis AGE
document structure decider framework (.trellis/ three-piece suite) domain (each project differs)
cross-cutting constraints 5 core principles + framework structural mandates progressive disclosure + normative/historical separation
history in spec allowed and encouraged (Case Study, Cautionary Tale) strictly excluded (only reason for choice and negative space retained)
carrier for history no dedicated carrier (journal rotates, tasks archived) bugs/, logs/, plans/, lessons/
spec bloat risk exists (knowledge only enters, never leaves) low (owner doc retains only current state)
spec readability high (causal context available in place) requires cross-file references for context

5. Plans: Closure Contracts, Not Task Lists

An AGE plan is not "get this thing done," but establishing verifiable closure conditions for fully autonomous AI execution.

The Full Lifecycle of a Plan

An AGE plan has three key gates, all completed by independent AI sub-agents:

  1. Draft review: an independent sub-agent audits whether the scope is honest, closure gates are real, and hidden dependencies exist.
  2. Execution: the AI executes around the plan, recording focused proof at each step, owner doc synchronization, and verification results.
  3. Closure audit: another independent sub-agent returns to the live repository and re-checks — independently verifying code, documentation, tests, and whether the closure conditions are truly satisfied.

The nop-chaos-flux plan guide (403 lines, 24 minimal rules) explicitly requires:

  • Rule 8: "completed must come from a separate closure audit"
  • Rule 12: "Before marking completed, a closure audit performed by an independent reviewer or independent sub-agent must be completed"
  • Rule 11: "When closing a plan, one must distinguish 'contract surface has appeared' from 'contract semantics have landed'"

Gradually Advancing Toward Full Automation

AGE’s overall goal is to gradually reduce human intervention nodes. In current practice, humans still control a few key nodes (defining attractors, arbitrating conflicts, calibrating direction), but the draft review and closure audit of plans are already fully completed by independent AI sub-agents. The future direction: humans control only input and final output, with sampling-based monitoring of intermediate processes.

first-principles-of-agent-engineering.md defines the essence of an Agent: "An Agent is a system that, under goal constraints, maintains, verifies, corrects, and reuses actionable cognitive structures across time." A plan is a local carrier for verification and correction — it defines "what it truly means for this round of expansion to be complete," and then an independent sub-agent verifies it.

Comparison with Trellis

Trellis’s plan/execution system has two layers:

First layer: PRD (design document + requirements document). Trellis’s prd.md is closer to a design document than pure requirements — containing Goal, Assumptions, Requirements, Acceptance Criteria, Out of Scope, Decisions (ADR-lite), and Technical Notes. It is co-created with the user through collaborative brainstorming in Phase 1.

Second layer: generic execution flow. workflow.md defines a universal 3-phase execution list for each task: Phase 1 (1.0–1.5: create task → explore requirements → research → configure context → activate) → Phase 2 (2.1–2.3: implement → quality check → rollback) → Phase 3 (3.1–3.5: quality verification → debug post-mortem → spec update → commit → wrap-up). Phase 2 implementation and checks are done autonomously by sub-agents; the Phase 3.4 commit requires a one-shot user confirmation.

Comparison of AGE’s plan vs. Trellis’s PRD + execution flow:

Dimension Trellis PRD + 3-phase flow AGE Plan
plan content PRD: design + requirements + technical approach + acceptance criteria Goals/Non-Goals/Closure Gates/execution items
execution list generic (workflow.md 3 phases, shared by all tasks) custom (each plan has its own Fix/Decision/Proof execution items)
Current Baseline none mandatory: check live repository before execution
Non-Goals present (Out of Scope section) mandatory: prevent scope drift
Closure Gates present (Acceptance Criteria, self-checked by implementer) mandatory: closure conditions, verified by independent sub-agent
Draft review none independent sub-agent audit
Closure audit none (implementer self-checks against Acceptance Criteria) independent sub-agent returns to live repository to verify
completion decision self-check before Phase 3.4 commit evidence from independent closure audit
human role participates in PRD collaboration and commit confirmation does not review intermediate plans, controls only input and final output
automation target human always in the loop gradually advancing toward full automation

Logs: Automatically Recorded Trajectory

AGE’s AGENTS.md mandates: "After completing any significant code change, you MUST update the daily dev log."

nop-chaos-flux’s docs/logs/2026/ directory contains 72 daily log files, each recording: specifically which workstream of which plan was closed, which code paths were modified (precise to file:line), which focused proofs passed, which owner docs were synchronously updated, repository-wide verification status, and the subagent task ID of the independent closure audit.

Trellis’s equivalent is workspace/journal-N.md — personal session memory, rotating after 2000 lines. It does not record precise code paths and verification baselines, and has no connection to plans.

6. Audit System: Shared Executive Checks + AGE’s Unique Directional Audit

Both AGE and Trellis have code quality gates. The difference is that AGE adds a layer of directional audit.

Common Ground: lint/test/typecheck as Commit Gates

Trellis’s Phase 2.2 (Quality check) and Phase 3.1 (Quality verification) require running pnpm lint && pnpm typecheck && pnpm test, encapsulated by the trellis-check skill.

AGE also has mandatory gates. nop-chaos-flux’s plan guide requires pnpm typecheck/build/lint/test all green to close a plan; nop-entropy’s AGENTS.md requires ./mvnw test -pl <affected-module> -am passes, and Rule 13 explicitly states, "fixed rules that have entered lint, static check scripts, or CI fail-fast are non-negotiable hard constraints." nop-entropy’s pre-commit hook also enforces code formatting checks. The two are equivalent at this level.

Trellis Unique: 5-Dimension Post-Mortem

trellis-break-loop provides structured bug post-mortems (Root Cause Category / Why Fixes Failed / Prevention / Systematic Expansion / Knowledge Capture), updating the spec after analysis.

AGE Unique: Overall Document-Code Consistency Audit

Deep Audit (deep-audit-prompts.md, 2141 lines, 20 dimensions) covers 6 categories:

Category Dimensions Audit Object
A. Architecture & Module Boundaries 01–03 dependency graph, module responsibilities, API surface area
B. Runtime & State 04–08 state ownership, reactive precision, async safety, lifecycle, validation consistency
C. Renderer & UI 09–12 renderer contract, style compliance, component usage, field modeling
D. Engineering Quality 13–15 type safety, test coverage, security & performance
E. Documentation & Consistency 16–18 document-code consistency, naming consistency, cross-package pattern consistency
F. Runtime Robustness 19–20 error propagation fidelity, accessibility

Dimensions 16–18 specifically audit consistency between documentation and code. Audit execution model: Phase 1 iterative deep dig (up to 10 rounds per dimension, independent sub-agent each round), Phase 2 independent re-verification (independent sub-agent returns to live code to re-confirm every finding).

Open-ended Adversarial Review (open-ended-adversarial-review-prompt.md) does not preset check dimensions, encouraging leapfrog exploration and self-negation, looping until no new findings emerge.

AGE adds directional audit: whether the owner doc matches the code, whether naming matches the glossary, whether the same concept is implemented consistently across packages. Deep-audit execution costs are extremely high (multiple rounds of independent sub-agents) — a trade-off that must be weighed.

7. Summary of Tool Comparison Between the Two

Dimension Trellis AGE (nop-chaos-flux / nop-entropy)
tool origin framework preset, available on install reverse-extracted from historical trajectory
new project startup cost trellis init gives full toolset AGE Template has only generic tools, but can reference open exemplars (nop-chaos-flux, nop-entropy) to quickly build domain-specific tools
tool evolution mechanism trellis update (framework upgrade) promotion ladder (bug → lesson → prompt → script → lint)
knowledge extraction from failures yes (break-loop 5-dimension analysis → spec prose) yes (promotion ladder → gradually automated tools)
knowledge artifact automation prose only prose → semi-automated scanning → fully automated interception
multi-platform adaptation core capability (14+ platforms) not a focus; depends on the host project’s CI
process automation core capability (state machine, hooks, sub-agents) limited (plan closure check scripts, pre-commit hook)
tool maintenance cost low (framework maintains uniformly) high (each tool needs whitelist and rule updates as the project evolves)
normative/historical separation not separated (history precipitated into spec) strictly separated (owner doc contains only current state)
plan system PRD requirement description closure contract (draft review + closure audit)
code quality gates yes (Phase 2.2/3.1: lint+typecheck+test) yes (plan guide Rule 13: hard gates non-negotiable)
post-mortem analysis yes (break-loop 5-dimension bug post-mortem) yes (bug note → lesson → skill promotion)
directional audit none yes (deep-audit 20 dimensions including document-code consistency)

8. Common Limitations: Trellis and OpenSpec Are Both Task-Level Tools

Trellis and OpenSpec have three structural deficiencies.

Deficiency One: No Repository-Wide Truth

The core organizational unit for Trellis and OpenSpec is the single change (a task / a change), not the repository as a whole.

  • Trellis: each task has its own prd.md; spec/ is a stack of coding conventions. There is no maintenance point for "what the system as a whole currently is and what it should converge to."
  • OpenSpec: specs/ claims to be source of truth, but it is an accumulation of requirements (each archive merges deltas, only adding, never removing), not a direction definition. The accumulated specs are a requirements list, not an architectural attractor.

AGE’s owner doc maintains the overall direction: which modules must be separated, the single direction that dependencies may flow, what concepts must not be mixed together.

AGE’s first-principles-of-agent-engineering.md distinguishes two sources of truth: four-dimensional truth (facts, causal source, confidence state, negative space) answers "what is and what was," while the attractor answers "what it should converge to." Trellis and OpenSpec do not distinguish these two sources — they only have "current specifications" (specs/spec), not "direction definition" (attractor).

Deficiency Two: No Trajectory Between Single Changes

  • Trellis: tasks are archived upon completion; journal rotates after 2000 lines. The next task cannot see what the previous task did, why those decisions were made, or what was rejected.
  • OpenSpec: changes are archived and kept in archive/, but they are only historical folders. There are no structured trajectory records (code paths, verification baselines, owner doc sync status). The next change does not learn from the execution process of the previous one.

AGE’s logs/ are mandatory trajectory: precise to code paths, focused proofs, owner doc sync, and verification baselines. bugs/ records negative space (which paths are excluded, which assumptions were falsified). Future sessions can recover from the trajectory "what happened up to yesterday."

This difference stems from the organizational unit: task-level tools care about "is this change correct," while a repository-level methodology cares about "after multiple consecutive AI changes, is the repository still heading in the right direction."

Deficiency Three: No Support Point for Evolving Toward Full AI Automation

  • Trellis: humans participate in PRD collaboration and commit confirmation; the 3-phase flow is designed for humans. There is no independent closure audit; humans do the final check.
  • OpenSpec: /opsx:propose and /opsx:verify both assume a human is in the loop. verify is optional, with no independent verification. tasks.md is a human-readable checklist.

AGE’s plan has draft review and closure audit completed by independent AI sub-agents; humans gradually withdraw. The plan is a closure contract, not a task list for humans. The attractor defines "converge to where," and the audit checks "are we converging" — neither requires human intervention.

AGE’s age-from-state-engineering-to-trajectory-engineering.md puts it directly: the basic structure of traditional software engineering is "state checks + human implicit direction sense." After deep AI participation, the human brain no longer holds the complete blueprint; the "direction sense" must be externalized into the repository structure. Trellis and OpenSpec both still rely on human implicit direction sense — they make single AI-human collaborations more reliable, but they do not replace human judgment of direction.

The Relative Progress of Trellis and OpenSpec

Each has progressed relative to the other, but both still circle within the task-level framework.

Trellis’s progress over OpenSpec:

  1. Knowledge write-back from failure to spec: trellis-break-loop (5-dimension bug analysis) → trellis-update-spec (mandatory spec file update). OpenSpec’s /opsx:archive only merges delta specs (requirement changes), and does not write back failure lessons — learned lessons stay in the archive folder and do not flow back into the specs.
  2. Complete execution pipeline: sub-agent dispatch (trellis-implement/trellis-check), jsonl context injection, rollback. OpenSpec only has an artifact dependency graph (proposal → specs → design → tasks), with no execution flow management — /opsx:apply relies on the AI to find and read specs on its own.
  3. Structured bug analysis: the 5-dimension analysis framework of trellis-break-loop (Root Cause Category / Why Fixes Failed / Prevention / Systematic Expansion / Knowledge Capture). OpenSpec has no equivalent.

OpenSpec’s progress over Trellis:

  1. Enforced spec validation: openspec validate parses Markdown with a Zod schema, mandating a Purpose section, Requirements section, at least one Scenario per Requirement, ADDED/MODIFIED must contain SHALL/MUST, and no cross-section conflicts. Trellis’s spec files are completely free Markdown with no structural validation.
  2. Delta mechanism: ADDED/MODIFIED/REMOVED incremental descriptions + merge on archive. More structured than Trellis’s "stuff all knowledge into spec files."
  3. Spec/Change separation: specs/ (source of truth) and changes/ (incremental modification) are kept separate. A step beyond Trellis’s non-distinction between specifications and proposals.

The spec format of OpenSpec has a fundamental limitation: the Given/When/Then Scenario is a format meant for machine verification (can be automatically converted into test cases), not a direction definition for humans to read. AGE’s owner doc is an architectural direction for humans to read ("modules must be separated," "dependencies can only flow in one direction"); the audiences of the two are different.

Three-Way Comparison Table

AGE Dimension AGE OpenSpec Trellis
organizational unit repository as a whole (attractor + trajectory) single change (change) single change (task)
nature of spec direction definition ("what it should converge to") behavioral description ("current behavior") coding conventions ("how to write code")
between changes trajectory records (logs + bugs + plans) archive folder (archive/) archive + rotating journal
negative space bugs/ (excluded paths) none none
closure verification independent AI sub-agent closure audit optional /opsx:verify (self-check) Acceptance Criteria (self-check)
full AI automation conceptually supported (plan = contract, not designed for humans) not considered (flow assumes human in the loop) not considered (3-phase flow designed for humans)
spec validation none (owner doc freely organized by domain) enforced (Zod schema + openspec validate) none (free Markdown)
knowledge promotion bug → lesson → skill → script → lint none (no progression after archive) none (break-loop output goes into spec and stops there)

9. The Co-Evolution of Theory and Practice

The thought of dynamical systems (state space → attractor → trajectory → control) was the earliest conceptual framework established by AGE. But the specific implementation — what structure the owner doc uses, how closure audits are done, how the promotion ladder is designed — has been continuously adjusted in practice.

The evolutionary history of nop-chaos-flux:

  • Attractor carrier evolved from flat architecture documents to a 4-layer priority system — solidified only after multiple audits revealed priority conflicts.
  • Closure audit evolved from manual checking to mandatory independent sub-agent verification — established after Plan 143’s closure hypothesis was repeatedly overturned.
  • The promotion ladder was not designed at the beginning; it gradually formed after discovering that "prose-only lessons cannot prevent the same error from recurring."
  • Open-ended adversarial review emerged because the fixed dimensions of deep-audit sometimes missed problems outside those dimensions.

What specific document structures carry attractors, what mechanisms check deviation — guided by the dynamical systems thought, they are continuously calibrated and refined through practice.

Trellis comes from practical observations ("what practices work in AI engineering"); the 5 core principles are empirical summaries. There is no derivation chain from theory to practice; expansion relies on stacking experiences.

Conclusion

Core finding: Trellis and OpenSpec both use the single change as the organizational unit, while AGE uses the overall repository trajectory as the organizational unit. The former cares about "is this change correct"; the latter cares about "after multiple consecutive AI changes, is the repository still heading in the right direction."

Specifically, the three diverge fundamentally in eight dimensions:

  1. Organizational unit: Trellis and OpenSpec are task-level tools (a task / a change); AGE is a trajectory-level methodology (repository as a whole). This is the most fundamental difference, and all the following divergences derive from it.

  2. Where tools come from: Trellis’s 12 skills and OpenSpec’s slash commands are preset at framework design time, available out-of-the-box for new projects; AGE’s tools are reverse-extracted from historical trajectories, new projects start from the Template’s generic tools, but can accelerate by referencing open-source exemplars such as nop-chaos-flux, nop-entropy, and nop-chaos-next. They cater to different stage needs.

  3. Depth of knowledge extraction from failures: All three learn from failures. Trellis’s trellis-break-loop offers 5-dimension analysis; OpenSpec has an archive to retain change history; knowledge is precipitated as prose. AGE’s promotion ladder elevates the same pattern step by step into automated tools. The difference lies in the automation level of the artifacts.

  4. Nature of spec: OpenSpec’s specs are structured behavioral contracts (Requirement + Scenario), closer to "executable contracts" than Trellis’s coding conventions. But neither distinguishes "current behavior" from "what it should converge to." AGE’s owner doc is a direction definition, not a requirements description.

  5. Continuity between single changes: Trellis (task archive + journal rotation) and OpenSpec (archive folder) both lack structured trajectory records. AGE’s logs are precise to code paths and verification baselines; bugs record negative space.

  6. Support for evolving toward full AI automation: Trellis and OpenSpec’s processes both assume a human in the loop. AGE’s plan is a closure contract; draft review and closure audit are completed by independent AI sub-agents, and humans gradually withdraw.

  7. Audit layers: All three have code quality gates. AGE adds directional audit (deep-audit 20 dimensions including document-code consistency), checking "whether the system is converging in the right direction," but at an extremely high execution cost.

  8. Theory generation vs. experience stacking: AGE starts from dynamical systems thinking; practical elements can be deduced from the theory. Trellis and OpenSpec come from practical observations; expansion relies on experience stacking.

References

AGE Methodology:

nop-chaos-flux (AGE instance):

  • GitHub: https://github.com/entropy-cloud/nop-chaos-flux
  • Gitee: https://gitee.com/canonical-entropy/nop-chaos-flux
  • docs/skills/README.md — index of 22 skills/prompts
  • docs/skills/deep-audit-prompts.md — 2141 lines, 20-dimension deep audit framework
  • docs/skills/open-ended-adversarial-review-prompt.md — open-ended adversarial review
  • docs/skills/bug-diagnosis-prompt.md — diagnostic methodology extracted from 66+ bugs
  • docs/plans/00-plan-authoring-and-execution-guide.md — 403 lines, 24 minimal rules
  • scripts/audit/ — 15 files (including 11 scanners + rules/shared modules)
  • docs/bugs/ — 66 bug fix histories
  • docs/articles/first-principles-of-agent-engineering.md — 276 lines, fundamental principles of agent engineering
  • docs/articles/age-from-state-engineering-to-trajectory-engineering.md — From State Engineering to Trajectory Engineering

nop-entropy (AGE instance):

nop-chaos-next (AGE instance):

Top comments (0)