@jaimevalasek/aioson 1.8.0 → 1.9.1

package/template/.aioson/docs/sheldon/quality-lens.md

@@ -1,57 +1,57 @@
----
-description: "Sheldon quality lens — high-signal enrichment patterns, anti-pattern replacements, and a compact review rubric."
----
-
-# Sheldon Quality Lens
-
-Load this module before presenting improvements, sizing, or phased planning.
-
-## Positive patterns
-
-High-quality Sheldon output usually does all of this:
-
-- isolates the few gaps that would actually break downstream work
-- distinguishes product gaps, technical gaps, and execution gaps
-- ranks recommendations by severity and evidence, not by verbosity
-- preserves `@product` ownership of vision, users, and problem framing
-- uses fresh validation when technology or domain assumptions may have aged
-- recommends a phased plan only when complexity or risk justifies it
-
-## Anti-patterns and replacements
-
-| Anti-pattern | Replace with |
-|---|---|
-| Rewriting the PRD with different words | Referencing sections and proposing targeted deltas |
-| Long lists of equal-priority suggestions | A short, ordered set of critical improvements |
-| Technical speculation without evidence | Evidence-backed validation or explicit uncertainty |
-| Cosmetic refinements presented as blockers | Clear separation between critical and optional changes |
-| Phase plan created by reflex | A justified decision tied to scope, dependencies, or risk |
-
-## Elevation moves
-
-Before finalizing, strengthen at least one item in each area:
-
-- evidence quality
-- severity ordering
-- downstream actionability
-- freshness validation
-
-## Review scorecard
-
-Score from `1-5` on:
-
-- criticality
-- evidence strength
-- prioritization clarity
-- downstream usefulness
-- execution realism
-
-If any score is `3` or lower, tighten the output before presenting it.
-
-## Final pass
-
-Ask silently:
-
-- Would `@dev` or `@qa` materially avoid rework because of this enrichment?
-- Did I separate confirmed issues from optional upgrades?
-- If I proposed a phased plan, is the reason strong enough to defend?
+---
+description: "Sheldon quality lens — high-signal enrichment patterns, anti-pattern replacements, and a compact review rubric."
+---
+
+# Sheldon Quality Lens
+
+Load this module before presenting improvements, sizing, or phased planning.
+
+## Positive patterns
+
+High-quality Sheldon output usually does all of this:
+
+- isolates the few gaps that would actually break downstream work
+- distinguishes product gaps, technical gaps, and execution gaps
+- ranks recommendations by severity and evidence, not by verbosity
+- preserves `@product` ownership of vision, users, and problem framing
+- uses fresh validation when technology or domain assumptions may have aged
+- recommends a phased plan only when complexity or risk justifies it
+
+## Anti-patterns and replacements
+
+| Anti-pattern | Replace with |
+|---|---|
+| Rewriting the PRD with different words | Referencing sections and proposing targeted deltas |
+| Long lists of equal-priority suggestions | A short, ordered set of critical improvements |
+| Technical speculation without evidence | Evidence-backed validation or explicit uncertainty |
+| Cosmetic refinements presented as blockers | Clear separation between critical and optional changes |
+| Phase plan created by reflex | A justified decision tied to scope, dependencies, or risk |
+
+## Elevation moves
+
+Before finalizing, strengthen at least one item in each area:
+
+- evidence quality
+- severity ordering
+- downstream actionability
+- freshness validation
+
+## Review scorecard
+
+Score from `1-5` on:
+
+- criticality
+- evidence strength
+- prioritization clarity
+- downstream usefulness
+- execution realism
+
+If any score is `3` or lower, tighten the output before presenting it.
+
+## Final pass
+
+Ask silently:
+
+- Would `@dev` or `@qa` materially avoid rework because of this enrichment?
+- Did I separate confirmed issues from optional upgrades?
+- If I proposed a phased plan, is the reason strong enough to defend?

package/template/.aioson/docs/sheldon/research-loop.md

@@ -1,56 +1,56 @@
----
-description: "Sheldon research loop — extract short keyword phrases from the PRD and sources, consult research cache, and use fresh findings to prioritize enrichment."
----
-
-# Sheldon Research Loop
-
-Load this module after source consolidation and before sizing.
-
-## Goal
-
-Give `@sheldon` a lightweight but mandatory fresh-research pass so enrichment decisions are not limited to the PRD text or the user-supplied sources.
-
-## Mandatory keyword extraction
-
-Derive `3-7` short keyword phrases from:
-
-- the PRD's riskiest assumptions
-- unresolved flows or business rules
-- integrations, vendors, or external systems
-- domain nouns that affect quality
-- differentiators or market claims
-- technical patterns that may have aged
-
-Keep phrases short, concrete, and searchable. Prefer `2-6` words.
-
-## Mandatory scouting pass
-
-1. Load `.aioson/skills/static/web-research-cache.md`
-2. Rank phrases by:
-   - staleness risk
-   - chance of changing the PRD or phase plan
-   - risk to downstream implementation
-3. Reuse fresh `researchs/` hits first
-4. Search only the top `1-4` stale or missing phrases
-5. Save every result before using it
-
-At least one phrase must be validated through cache or fresh research whenever the PRD touches an external market, evolving UI pattern, vendor dependency, compliance surface, or non-trivial technical choice.
-
-## How to use the findings
-
-Use research to:
-
-- reprioritize improvements
-- distinguish critical gaps from cosmetic refinements
-- justify whether phased planning is necessary
-- challenge stale technical or product assumptions
-- enrich edge cases and operational details
-
-If the research is purely technical and tied to named stack decisions, combine this module with `.aioson/docs/sheldon/web-intelligence.md`.
-
-## Output discipline
-
-- `researchs/` is a temporary shared evidence layer, not a substitute for the PRD
-- show only findings that change priority, sizing, or correctness
-- mark inference separately from sourced facts
-- do not force enrichment changes without user confirmation
+---
+description: "Sheldon research loop — extract short keyword phrases from the PRD and sources, consult research cache, and use fresh findings to prioritize enrichment."
+---
+
+# Sheldon Research Loop
+
+Load this module after source consolidation and before sizing.
+
+## Goal
+
+Give `@sheldon` a lightweight but mandatory fresh-research pass so enrichment decisions are not limited to the PRD text or the user-supplied sources.
+
+## Mandatory keyword extraction
+
+Derive `3-7` short keyword phrases from:
+
+- the PRD's riskiest assumptions
+- unresolved flows or business rules
+- integrations, vendors, or external systems
+- domain nouns that affect quality
+- differentiators or market claims
+- technical patterns that may have aged
+
+Keep phrases short, concrete, and searchable. Prefer `2-6` words.
+
+## Mandatory scouting pass
+
+1. Load `.aioson/skills/static/web-research-cache.md`
+2. Rank phrases by:
+   - staleness risk
+   - chance of changing the PRD or phase plan
+   - risk to downstream implementation
+3. Reuse fresh `researchs/` hits first
+4. Search only the top `1-4` stale or missing phrases
+5. Save every result before using it
+
+At least one phrase must be validated through cache or fresh research whenever the PRD touches an external market, evolving UI pattern, vendor dependency, compliance surface, or non-trivial technical choice.
+
+## How to use the findings
+
+Use research to:
+
+- reprioritize improvements
+- distinguish critical gaps from cosmetic refinements
+- justify whether phased planning is necessary
+- challenge stale technical or product assumptions
+- enrich edge cases and operational details
+
+If the research is purely technical and tied to named stack decisions, combine this module with `.aioson/docs/sheldon/web-intelligence.md`.
+
+## Output discipline
+
+- `researchs/` is a temporary shared evidence layer, not a substitute for the PRD
+- show only findings that change priority, sizing, or correctness
+- mark inference separately from sourced facts
+- do not force enrichment changes without user confirmation

package/template/.aioson/docs/sheldon/web-intelligence.md

@@ -1,75 +1,75 @@
----
-description: "Sheldon web intelligence protocol — stale-tech validation, research cache, verdicts, and output rules."
----
-
-# Sheldon Web Intelligence
-
-Load this module when the target PRD names technologies, frameworks, integrations, or technical patterns that may be stale.
-
-## Goal
-
-Validate whether the technical decisions mentioned in the PRD are still good choices as of today.
-
-## When to run
-
-Run after source consolidation and before sizing.
-If the PRD contains no specific technical decisions, skip silently.
-
-## Technical signals to extract
-
-Look for:
-
-- named technologies or frameworks
-- architectural patterns
-- external integrations
-- stack decisions
-
-## Search protocol
-
-For each high-risk technical signal:
-
-1. Check `researchs/{decision-slug}/summary.md`
-2. If a result exists and is less than 7 days old, reuse it
-3. Otherwise search using the current year
-4. Classify the result as:
-   - `confirmed`
-   - `has-alternatives`
-   - `outdated`
-   - `deprecated`
-
-Max 4 searches per session.
-
-## Save to `researchs/`
-
-For each search, create:
-
-- `researchs/{decision-slug}/summary.md`
-- raw consulted pages under `researchs/{decision-slug}/files/`
-
-`summary.md` frontmatter must include:
-
-- `searched_at`
-- `agent: sheldon`
-- `prd`
-- `query`
-- `verdict`
-
-## User-facing output rule
-
-Show only actionable findings:
-
-- `has-alternatives`
-- `outdated`
-- `deprecated`
-
-If every finding is `confirmed`, tell the user no update is needed.
-
-Never silently modify the PRD based on web validation.
-Ask whether to incorporate the update first.
-
-## Failure behavior
-
-If a search fails:
-
-- log the failure in `summary.md`
-- continue without blocking the session
+---
+description: "Sheldon web intelligence protocol — stale-tech validation, research cache, verdicts, and output rules."
+---
+
+# Sheldon Web Intelligence
+
+Load this module when the target PRD names technologies, frameworks, integrations, or technical patterns that may be stale.
+
+## Goal
+
+Validate whether the technical decisions mentioned in the PRD are still good choices as of today.
+
+## When to run
+
+Run after source consolidation and before sizing.
+If the PRD contains no specific technical decisions, skip silently.
+
+## Technical signals to extract
+
+Look for:
+
+- named technologies or frameworks
+- architectural patterns
+- external integrations
+- stack decisions
+
+## Search protocol
+
+For each high-risk technical signal:
+
+1. Check `researchs/{decision-slug}/summary.md`
+2. If a result exists and is less than 7 days old, reuse it
+3. Otherwise search using the current year
+4. Classify the result as:
+   - `confirmed`
+   - `has-alternatives`
+   - `outdated`
+   - `deprecated`
+
+Max 4 searches per session.
+
+## Save to `researchs/`
+
+For each search, create:
+
+- `researchs/{decision-slug}/summary.md`
+- raw consulted pages under `researchs/{decision-slug}/files/`
+
+`summary.md` frontmatter must include:
+
+- `searched_at`
+- `agent: sheldon`
+- `prd`
+- `query`
+- `verdict`
+
+## User-facing output rule
+
+Show only actionable findings:
+
+- `has-alternatives`
+- `outdated`
+- `deprecated`
+
+If every finding is `confirmed`, tell the user no update is needed.
+
+Never silently modify the PRD based on web validation.
+Ask whether to incorporate the update first.
+
+## Failure behavior
+
+If a search fails:
+
+- log the failure in `summary.md`
+- continue without blocking the session