Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/decision-rain-library-project/llms.txt

Use this file to discover all available pages before exploring further.

Decision rules govern how the AI assistant assigns tags to each entry. Every rule has a clear condition — these are not guidelines for approximate use; they are the constraints that keep the library consistent and interrogable over time. When the assistant follows these rules, the library remains trustworthy. When a rule is ambiguous, the assistant stops and asks the operator rather than inferring a path forward.

​
Status Rules

The status/* tag records the current operational decision about an entry. Every evaluated entry must carry exactly one status value. Status is a proposal from the assistant; it does not become canonical until the operator validates it.
Use when the entry warrants immediate, careful examination. The item may have high relevance, surprising implications, or significant risk that needs to be understood before any other action. status/dissect is a call to attention, not a verdict.
Use when the item can be used or applied with low ambiguity and the operator has confirmed acceptable StackFit. This is the highest practical endorsement in the library. Do not assign status/ready unless fit is acceptable and the operator has validated the decision — it must never be proposed by the assistant alone.
Use when the item has clear value but does not address a current need. status/later is not dismissal — it preserves the entry for future retrieval when conditions change.
Use when the underlying idea, pattern, or approach is worth preserving even though the specific implementation, technology stack, or adoption path is not practical for the operator right now. Pair with next/extract to signal that the idea should be pulled out rather than the tool adopted.
Use when the item needs monitoring before a decision can be made. Reasons to watch include: maturity is uncertain, pricing is unclear or changing, maintenance is irregular, ecosystem is evolving, access constraints are ambiguous, or community friction is notable. status/watch is not a positive or negative signal — it is a signal that the situation is not yet stable enough to decide.
Use when the item has been evaluated and is not worth adopting, extracting, or watching — except as historical evidence of what was considered. status/rejected is a permanent record, not a soft decline. Do not use it for items that might be useful later; use status/later or status/watch for those.
Use when the item’s primary value is as documentation, a directory, a guide, or learning material rather than something to adopt or act on. Reference entries are kept because they may be retrieved and consulted, not because they represent a decision to do something.
Use when the assistant has processed and saved the entry but the operator has not yet reviewed or confirmed it. status/pending-review is the default state for all assistant-generated proposals. Do not treat a pending-review entry as a canonical library entry — it is a draft awaiting operator confirmation.

​
Next Action Rules

Always add one next/* tag per evaluated entry. The next/* tag records the most specific, concrete next action. It must never be omitted from an evaluated entry. Choose the value that most precisely describes what should happen next, not the most generic available option.
Use when the item is ready to be tried with a real setup in the operator’s actual environment. next/test implies the capability exists and is accessible — this is not exploratory; it is a concrete verification step.
Use when the item needs investigation but the outcome is uncertain. A spike is time-boxed and question-driven — it ends with a report, not necessarily an adoption decision. Use next/spike rather than next/test when the core question is whether the item is even viable for the operator’s context.
Use when the value lies in the approach, pattern, or idea rather than the specific implementation. Pair with status/core-good when the concept is strong but the tool is not adoptable.
Use when the item is worth keeping but not actionable now. next/revisit is not passive archiving — it implies a concrete intention to return when conditions change (a project starts, a capability becomes needed, pricing improves). If there is no such intention, use next/archive instead.
Use when evaluation is complete and the entry is not worth keeping in active collections. The item may still have historical value as a record of what was considered and why it was passed over.
Use when the item is confirmed ready to be integrated into the operator’s active workflow. next/deploy implies that both the decision and the practical path are clear. Do not use it as a synonym for status/ready — deployment means the integration work is about to begin.

​
Authority Rules

The authority/* tag records the type of source behind the evidence. Use it to make the evidentiary basis of a decision explicit. A single entry may carry multiple authority/* tags when evidence comes from more than one source type.
Official evidence shows intended behavior — what the project or product claims to do, how it is meant to be used, and what the maintainers assert. It does not show real-world friction, edge cases, or community experience.
Source-code evidence is primary and verifiable. It shows what the project actually does, not just what it claims. Prefer authority/source-code over authority/official when you can inspect the code directly.
Community evidence shows real-world friction — what users actually experience, what breaks in practice, what pricing surprises emerge, and what the ecosystem looks like outside the official narrative. Keep community evidence separate from official evidence; they answer different questions.Community evidence can raise risk; it does not automatically override official evidence unless the concern is material, repeated, and directly relevant to the operator’s use case.
Vendor claims are the weakest form of evidence. They record what the vendor asserts without independent verification. Always pair authority/vendor-claim with a matching truth/* value — typically truth/claimed or truth/plausible — and look for corroborating community or source-code evidence before raising confidence.
Internal authority captures decisions, rules, or judgments that originate within the operator’s own context — not from an external source. Use it for entries whose classification depends on operator-specific knowledge that cannot be sourced externally.

​
Truth Rules

The truth/* tag records the confidence level of the key claim. It is not a quality rating — it is an honest assessment of how well the claim is supported by the available evidence at the time of cataloging.
Use when the claim is confirmed by primary evidence: a working test, direct inspection of source code, or strong corroboration from multiple independent sources. truth/verified is a high bar — do not use it for claims that are merely plausible or well-sourced.
Use when the claim is likely true based on available evidence but has not been confirmed by a direct test or primary inspection. truth/plausible is honest — it acknowledges good evidence without overstating certainty.
Use when the claim comes from the vendor or author and has not been independently verified. Pair with authority/vendor-claim. The claim may be accurate, but no independent evidence has been found to confirm it.
Use when credible sources present genuinely contradictory information about the same claim. Surface the conflict explicitly in the evidence note. Do not suppress one side to reach a cleaner verdict — the conflict is the finding.
Use when the claim may have been accurate at some point but the evidence suggests the information is no longer current — a stale README, an unmaintained project, pricing that has changed, or a deprecated feature.
Use when there is not enough evidence to assess the claim in either direction. truth/unknown is not a failure — it is an honest record of an evidence gap. It may prompt a next/spike or next/test to gather more information.

​
Fit Rules

Fit rules govern how practical compatibility is assessed and how it affects the status decision. StackFit is the underlying judgment — the fit/* tags capture its components.
  • Never mark status/ready unless fit is acceptable and the operator has validated. Fit assessment alone is insufficient — the operator must confirm the adoption decision.
  • A project can be status/core-good if the idea is strong but implementation fit is bad. Poor fit does not mean the entry has no value. When the idea is worth preserving, use status/core-good and pair it with next/extract.
  • Directories and mega-lists often use fit/discovery-only. The directory itself is not the adoptable artifact. Each candidate within it must be evaluated separately before any adoption decision.
  • Poor implementation fit does not mean worthless. It may mean extract, reference, watch, or later — depending on the nature of the value and the operator’s situation.
  • Always separate Claim from Evidence before Verdict. The claim states what the item appears to provide. Evidence states what supports or weakens the claim. The verdict states the practical judgment after weighing both. Conflating them produces unreliable decisions.

​
Evidence Conflict Rules

Evidence conflicts require explicit handling — they must not be suppressed, averaged, or resolved by choosing the more convenient source. When official and community evidence conflict, surface the conflict before deciding. Record both sides in the evidence note. Assign truth/conflicting and explain the nature of the disagreement. Community evidence can raise risk and change the confidence level of official claims. It does not automatically override official evidence. To override official evidence, community evidence must be:
  • Material — the concern is significant enough to change the practical decision
  • Repeated — the signal appears across multiple independent sources
  • Relevant — the concern applies to the operator’s specific use case, not a different context
If a conflict between evidence sources changes the decision — affecting status, truth, StackFit, next action, or promotion — the assistant must stop and ask the operator before proceeding. Do not resolve material conflicts unilaterally.

Build docs developers (and LLMs) love

Get started for freeTalk to us