Tool profile · provisional profile

Cline memory-bank

Useful project-scoped convention. Strong because it is human-readable, weak if it becomes stale project lore without promotion discipline.

Provisional fit

62/100

Best for: Coding-agent projects where repo-local context should be inspectable and versioned with the work.

Avoid if: you need a fully governed, citation-complete knowledge architecture without adding policy, evidence capture, and review workflow around the tool.

Caution: Files are easy to inspect but easy to rot. Context assembly and freshness checks need process support.

Model signature: Storage primary · repo scope · Repo pattern

Layer coverage

Where this tool fits.

This is not a completed review. It is a provisional profile from public positioning plus known failure-mode mapping. Hands-on benchmarks, source snapshots, and citation-bound claims are still required before stronger conclusions.

Production
Curation
Storage
Context Assembly
Governance
Review rule: a tool does not get credit for a layer unless it exposes inspectable behavior, not just a marketing claim.

Evidence notes

What the provisional profile has applied so far.

Research pass treats file-based memory as useful for auditability and human correction.

Mapped to storage because the central move is canonical, readable project records rather than embeddings or hidden state.

Needs tests for update discipline, stale instruction detection, promotion from chat to files and conflict handling.

Review packet

What a complete review must contain.

This page exposes the intended review structure. The current artifact is a profile, not a completed evidence-backed review.

Strengths

Coding-agent projects where repo-local context should be inspectable and versioned with the work.

Limitations

Files are easy to inspect but easy to rot. Context assembly and freshness checks need process support.

Dimension assessment

Scope, volatility, authority, lifecycle, resource economics, interoperability, and evidence quality must each get a rationale and citations before final scoring.

Open questions

  • What can be verified from docs, code, issues, benchmarks, and changelogs?
  • Where does the tool fail under stale, contradictory, private, or high-cost knowledge?
  • Which claims are vendor claims versus independently observed behavior?

Benchmark critique

No benchmark number is accepted as architectural evidence unless it says which layer it tests and what it misses: lifecycle, scope boundaries, authority, context cost, and governance.

Related systems

Related tools should be connected by evidence-backed edges: competes with, integrates with, implements concept, evaluated by, or has governance gap.

Update history

Provisional profile created. Stale-review detection, source snapshots, and changelog watching are required before this becomes a durable review.