ai-playbook 1.0.0

package/context/aem.md

@@ -0,0 +1,47 @@
+# AEM Context
+
+Use this context for Adobe Experience Manager projects, components, templates,
+content workflows, and platform integrations.
+
+## AEM Principles
+
+- Respect the separation between content, presentation, component logic, and
+  deployment configuration.
+- Prefer reusable components with clear authoring dialogs and predictable content
+  models.
+- Keep author experience, accessibility, performance, and cacheability in view.
+- Follow existing project conventions for Sling models, HTL, client libraries,
+  policies, templates, and content packages.
+
+## Component Work
+
+- Define the authoring use case before changing dialogs or component behavior.
+- Keep component APIs stable for existing content when possible.
+- Validate required fields and provide useful author-facing labels/help text.
+- Ensure HTL output is semantic, accessible, and safely escaped.
+- Include empty, authored, error, and publish-mode states where relevant.
+
+## Content And Templates
+
+- Document allowed components, policies, editable templates, and layout
+  constraints.
+- Avoid hardcoding content that should be author-managed.
+- Preserve content compatibility during migrations.
+- Treat taxonomy, tagging, localization, and DAM asset usage as part of the
+  content model.
+
+## Performance And Delivery
+
+- Design components to be cache-friendly for dispatcher/CDN layers.
+- Keep client libraries scoped and avoid shipping unused JavaScript or CSS.
+- Optimize images, responsive media, and Core Web Vitals.
+- Watch for expensive repository queries, excessive includes, and uncached
+  personalized fragments.
+
+## Testing And Release
+
+- Test authoring dialogs, publish rendering, permissions, and content migration.
+- Verify accessibility, responsive behavior, and browser support.
+- Include package filters, run modes, OSGi configs, and deployment notes when
+  relevant.
+- Provide rollback or content recovery guidance for risky releases.

package/context/architecture.md

@@ -0,0 +1,51 @@
+# Architecture Context
+
+Use this file for default architectural judgment across projects when no more
+specific project architecture is available.
+
+## Architecture Principles
+
+- Start from the user goal, domain model, and operational constraints.
+- Prefer boring, proven technology unless the problem clearly benefits from a
+  specialized tool.
+- Keep boundaries explicit: ownership, data contracts, failure modes, and
+  deployment responsibilities should be clear.
+- Optimize for maintainability, observability, and safe change before novelty.
+- Treat security, privacy, reliability, and cost as architectural dimensions, not
+  afterthoughts.
+
+## Design Defaults
+
+- Favor modular systems with small, testable units and well-defined interfaces.
+- Keep business logic out of transport, UI, and persistence glue where practical.
+- Use typed contracts, schemas, or validation at trust boundaries.
+- Make external dependencies replaceable enough to test and recover from
+  failures.
+- Prefer idempotent operations for retries, jobs, webhooks, and message handlers.
+
+## Data And Integration
+
+- Identify source of truth, ownership, retention, and privacy requirements for
+  important data.
+- Document read/write paths and consistency expectations.
+- Version public APIs, event schemas, and cross-team contracts.
+- Design for replay, backfill, and migration when data changes over time.
+- Avoid leaking implementation details across service or module boundaries.
+
+## Reliability And Operations
+
+- Define health checks, dashboards, alerts, and runbooks for production-facing
+  systems.
+- Include rollback or mitigation paths for risky changes.
+- Prefer graceful degradation for non-critical dependencies.
+- Capture capacity assumptions and expected growth.
+- Review failure modes before launch, especially queues, caches, databases, and
+  third-party APIs.
+
+## Architecture Review Checklist
+
+- The problem and success criteria are clear.
+- Alternatives and trade-offs are documented.
+- The proposed design has clear owners and boundaries.
+- Security, privacy, reliability, cost, and operability have been considered.
+- Risks have mitigations, decision owners, and review dates.

package/context/bullminder.md

@@ -0,0 +1,57 @@
+# BullMinder Context
+
+Use this context for BullMinder-related tasks. BullMinder is treated as a
+trading assistant and monitoring system unless a project-specific file provides
+more precise details.
+
+## Product Intent
+
+- Help identify, explain, monitor, and review trading opportunities.
+- Keep watchlists, alerts, outcomes, and learning loops grounded in observable
+  market data.
+- Support disciplined decision-making rather than impulsive execution.
+- Make risk, uncertainty, and invalidation visible.
+
+## Agent Behavior
+
+- Normalize symbols before tool calls, storage, alerts, or comparisons.
+- Separate discovery, validation, execution, monitoring, and outcome-learning
+  responsibilities.
+- Prefer structured tool calls and typed payloads over free-form parsing.
+- Do not treat fuzzy or unmatched PnL as a reliable learning signal.
+- Avoid duplicate intents within the configured cooldown window.
+
+## Opportunity Model
+
+Every opportunity should capture:
+
+- Symbol and market.
+- Setup type and time horizon.
+- Entry trigger, stop, target, invalidation, and position-size rationale.
+- Evidence summary from price action, volume, trend, news, fundamentals, or other
+  configured signals.
+- Confidence, risk, and reason for watchlist/no-trade outcomes.
+
+## Execution Safety
+
+- Default to paper trading or human confirmation unless live execution is
+  explicitly enabled.
+- Validate account mode, buying power, order type, market hours, and symbol
+  tradability before placing orders.
+- Enforce risk limits before execution.
+- Record every execution decision, including blocked and skipped actions.
+
+## Monitoring And Notifications
+
+- Alerts should be deduplicated, actionable, and tied to the original thesis.
+- Position monitoring should track stop, target, thesis invalidation, time stop,
+  and notable market events.
+- Notifications should include severity, event type, symbol, action requested,
+  and next review condition.
+
+## Review And Learning
+
+- Outcomes should be matched to explicit prior opportunities or positions.
+- Review should distinguish good process from good luck.
+- Learning updates should name the pattern, evidence, outcome, and confidence
+  adjustment.

package/context/coding-style.md

@@ -0,0 +1,42 @@
+# Coding Style Context
+
+Use this file for default coding style when a project does not provide stronger
+local conventions.
+
+## General Style
+
+- Follow the patterns already present in the repository.
+- Prefer readable names over clever abbreviations.
+- Keep functions small enough that their purpose and side effects are clear.
+- Avoid speculative abstractions; add one only when it removes real duplication
+  or complexity.
+- Keep comments focused on why a decision exists, not what each line does.
+- Preserve public behavior unless the task explicitly changes it.
+
+## Error Handling
+
+- Validate untrusted input at boundaries.
+- Return or raise errors with enough context to debug safely.
+- Avoid swallowing exceptions without logging, metrics, or a clear fallback.
+- Do not expose secrets, credentials, private data, or internal stack details in
+  user-facing errors.
+
+## Testing
+
+- Add or update tests when behavior changes.
+- Prefer tests that exercise user-visible behavior or stable contracts.
+- Cover success, failure, edge, and authorization cases when relevant.
+- When tests cannot be run, state exactly what was not verified.
+
+## Documentation
+
+- Update nearby docs, examples, or checklists when behavior or workflow changes.
+- Keep README content task-oriented and current.
+- Prefer concise examples that can be copied and adapted.
+
+## Review Readiness
+
+- Code is formatted by the project toolchain.
+- Lint, type, unit, and integration checks are run when available.
+- New dependencies are justified and consistent with project policy.
+- Temporary debug output, dead code, and stale TODOs are removed.

package/context/communication.md

@@ -0,0 +1,53 @@
+# Communication Context
+
+Use this guidance for human-facing updates, reviews, handoffs, and summaries.
+
+## Style
+
+- Be concise, specific, and grounded in evidence.
+- Name assumptions and uncertainty plainly.
+- Lead with the outcome, then provide supporting details.
+- Avoid vague claims like "fixed everything" or "tests pass" unless verified.
+
+## During Work
+
+When work takes more than a short moment:
+
+- Say what context is being gathered.
+- Explain what changed when the direction shifts.
+- Call out blockers early.
+- Keep updates short enough to stay useful.
+
+## Final Summaries
+
+Include:
+
+- What changed
+- Why it changed
+- Verification performed
+- Remaining risks or follow-ups
+
+## Handoffs
+
+When handing work to another human or agent:
+
+- State the current status and the next concrete step.
+- Name files, commands, or artifacts that matter.
+- Call out assumptions, skipped checks, and known risks.
+- Keep unresolved questions separate from completed work.
+
+## Review Feedback
+
+When reviewing work:
+
+- Put findings first.
+- Reference exact files and lines when possible.
+- Explain the behavior or risk, not just the preference.
+- Separate blocking issues from optional improvements.
+
+## Tone
+
+- Be direct without being abrupt.
+- Prefer plain language over process jargon.
+- Give enough context for decisions to be traceable.
+- Do not overstate certainty when evidence is incomplete.

package/context/company.md

@@ -0,0 +1,46 @@
+# Company Context
+
+Use this file for organization-level assumptions that should influence agent
+decisions across projects.
+
+## Default Assumptions
+
+- This playbook is a reusable personal/team knowledge base, not a single product
+  repository.
+- Prefer guidance that can work across small teams, solo projects, and growing
+  engineering organizations.
+- Do not assume a specific employer, customer, org chart, compliance program, or
+  internal tool unless a project-specific context file states it.
+- Treat user-provided project context as more authoritative than these defaults.
+
+## Operating Values
+
+- Practical execution over ceremony.
+- Clear ownership, small reversible steps, and visible trade-offs.
+- Security, privacy, reliability, and accessibility are baseline expectations.
+- Documentation should help future work move faster, not merely satisfy process.
+- AI assistance should make human judgment sharper, not hide uncertainty.
+
+## Decision Preferences
+
+- Choose simple approaches that can be explained and maintained.
+- Prefer incremental delivery when the cost of being wrong is meaningful.
+- Make assumptions explicit when facts are missing.
+- Document decisions close to the relevant role, skill, project, or context file.
+- Escalate irreversible, risky, or externally visible decisions for human review.
+
+## Collaboration Expectations
+
+- Communicate status clearly during long-running work.
+- Lead summaries with outcomes, then verification and remaining risk.
+- Keep recommendations grounded in evidence from the repository or supplied
+  context.
+- Separate reusable playbook guidance from project-specific facts.
+
+## Information Boundaries
+
+- Do not invent company policies, credentials, private systems, legal
+  requirements, or production access.
+- Mark unknowns plainly and suggest the smallest useful next step to resolve
+  them.
+- If context conflicts, prefer the most specific and most recent source.

package/context/engineering.md

@@ -0,0 +1,63 @@
+# Engineering Context
+
+This file defines the default engineering posture for AI-supported work in this
+playbook.
+
+## Principles
+
+1. Solve the requested problem completely.
+2. Prefer simple, maintainable changes.
+3. Reuse existing project patterns before adding new ones.
+4. Treat security, privacy, and reliability as baseline requirements.
+5. Verify work with tests, checks, review, or explicit reasoning.
+6. Document important decisions close to the work they affect.
+
+## Default Workflow
+
+```text
+Understand
+    |
+Inspect
+    |
+Design
+    |
+Implement
+    |
+Verify
+    |
+Document
+    |
+Summarize
+```
+
+## Quality Gates
+
+- Requirements and success criteria are understood.
+- Relevant role, skill, and project context are loaded.
+- Changes follow the local style and architecture.
+- Tests or equivalent verification are completed when possible.
+- Any skipped verification is named clearly.
+- Risks and follow-up work are documented.
+
+## Scope Control
+
+Keep changes focused on the requested outcome. Do not refactor unrelated areas
+unless the refactor is required to complete the task safely.
+
+## Decision Hierarchy
+
+When guidance conflicts, prefer sources in this order:
+
+1. Explicit user instructions for the current task.
+2. Project-specific context, README files, and local code patterns.
+3. Role, skill, and domain context from this playbook.
+4. General engineering best practices.
+
+## Implementation Defaults
+
+- Read before editing.
+- Preserve user changes and avoid reverting unrelated work.
+- Prefer structured parsers and project APIs over brittle text manipulation.
+- Keep changes reviewable and explain meaningful trade-offs.
+- Add verification proportional to risk and blast radius.
+- Leave the workspace in a state another engineer can understand.

package/context/project-template.md

@@ -0,0 +1,71 @@
+# Project Context Template
+
+Copy this structure into `projects/<project>/context.md` or adapt it inside a
+project-specific README.
+
+## Overview
+
+- **Project name:** 
+- **Purpose:** 
+- **Primary users:** 
+- **Business or personal goal:** 
+- **Current status:** Idea, prototype, active development, production, paused, or
+  archived.
+
+## Success Criteria
+
+- What outcome should this project produce?
+- What metric, behavior, or user signal proves it is working?
+- What constraints define "good enough" for the current phase?
+
+## Scope
+
+### In Scope
+
+- 
+
+### Out Of Scope
+
+- 
+
+## Users And Workflows
+
+- Primary user types:
+- Critical workflows:
+- Important edge cases:
+- Accessibility or device requirements:
+
+## Architecture
+
+- Runtime or framework:
+- Major modules or services:
+- Data stores:
+- External integrations:
+- Deployment target:
+- Local development command:
+
+## Engineering Constraints
+
+- Language and style expectations:
+- Testing expectations:
+- Security or privacy constraints:
+- Performance or reliability targets:
+- Dependency policy:
+
+## Operations
+
+- Environments:
+- Configuration and secrets:
+- Observability:
+- Backup or recovery:
+- Release and rollback:
+
+## Open Questions
+
+- 
+
+## Decision Log
+
+| Date | Decision | Reason | Owner |
+|------|----------|--------|-------|
+| | | | |

package/context/trading.md

@@ -0,0 +1,52 @@
+# Trading Context
+
+Use this context for trading-related projects, analysis tools, alerts, and AI
+agents. This is engineering and product guidance, not financial advice.
+
+## Core Principles
+
+- Treat market data as time-sensitive and verify freshness before acting on it.
+- Distinguish clearly between observation, model inference, recommendation, and
+  executed trade.
+- Preserve auditability: inputs, signals, assumptions, decisions, and outcomes
+  should be traceable.
+- Prefer risk management over prediction confidence.
+- Never imply guaranteed returns.
+
+## Data Expectations
+
+- Record the data source, symbol, timestamp, timezone, and market session.
+- Handle missing, delayed, split-adjusted, and stale data explicitly.
+- Separate historical backtest data from live or paper-trading data.
+- Normalize symbols and exchanges before comparing or storing results.
+- Avoid learning from unmatched, ambiguous, or manually corrected PnL unless the
+  source of truth is clear.
+
+## Strategy And Signal Hygiene
+
+- Define the setup type, entry trigger, invalidation point, position size, stop,
+  target, and time horizon.
+- Avoid mixing swing, day-trade, options, and long-term investing assumptions.
+- Track confidence as a function of evidence quality, not enthusiasm.
+- Make no-trade and watchlist outcomes first-class results.
+- Keep duplicate intent windows and cooldowns explicit for automated agents.
+
+## Risk Controls
+
+- Enforce max position size, max daily loss, max open risk, and per-symbol
+  exposure limits where applicable.
+- Confirm buying power, market hours, liquidity, spread, and order type before
+  execution.
+- Prefer paper trading or human confirmation until execution safeguards are
+  proven.
+- Log rejected trades with the exact rule that blocked them.
+
+## Verification
+
+- Backtests should account for survivorship bias, lookahead bias, slippage,
+  commissions, and realistic fills.
+- Live monitoring should compare expected state with broker or data-provider
+  state.
+- Alerts should include symbol, setup, trigger, stop, target, timestamp, and
+  reason.
+- Post-trade review should capture whether the original thesis played out.