crewly 1.4.38 → 1.4.40

package/config/templates/dev-fullstack/norms/code-commit-sop.md

@@ -1,114 +0,0 @@
-# Code Commit Standard Operating Procedure
-
-**Trigger**: before_commit
-**Applies to**: developer, team-leader
-**Version**: 1.0.0
-
-## Overview
-
-Every code commit to a feature branch must follow this 9-step process with 3 review
-rounds. This ensures code quality, consistency, and maintainability. The process is
-mandatory for all developers and team leaders on the dev-fullstack team.
-
-## Steps
-
-### Phase A: Preparation
-
-1. **Create Feature Branch**
-   - Branch from `main` using naming convention: `feat/`, `fix/`, `refactor/`, `chore/`
-   - One branch = one feature or fix
-   - Example: `git checkout -b feat/user-auth-flow`
-
-2. **Write Unit Tests**
-   - Place test files next to source files: `service.ts` → `service.test.ts`
-   - Cover: core business logic, conditionals, data transforms, error paths, edge cases
-   - Target: 80%+ coverage (100% for critical paths)
-   - Run: `npx jest --no-coverage` — all must pass
-
-3. **Create PR + Review Round 1 (Refactor & Consistency)**
-   - Open PR from feature branch → main
-   - Self-review focusing on:
-
-   | Dimension | Check |
-   |-----------|-------|
-   | Reusability | Can similar logic be extracted into shared utils? |
-   | Structure | Is any file too large or mixing responsibilities? |
-   | Modularity | Are module boundaries clean? Dependencies reasonable? |
-   | Consistency | Coding patterns consistent? (enums, naming, error handling) |
-   | Standards | Does code follow CLAUDE.md conventions? |
-
-   - Document findings as "Review Round 1 — Refactor & Consistency"
-
-### Phase B: Iterative Refinement
-
-4. **Apply Round 1 Changes**
-   - Refactor only — no new features
-   - Run tests to confirm passing
-   - Commit: `refactor: apply review round 1 feedback`
-
-5. **Review Round 2 (Efficiency & Reliability)**
-
-   | Dimension | Check |
-   |-----------|-------|
-   | Efficiency | Unnecessary computation? Duplicate processing? N+1 queries? |
-   | Null Safety | Are null/undefined checks sufficient? |
-   | Error Handling | Errors caught and logged properly? |
-   | Resource Cleanup | Timers, listeners, connections cleaned up? |
-   | Logging | Critical operations have adequate logs? |
-
-   - Document as "Review Round 2 — Efficiency & Reliability"
-
-6. **Apply Round 2 Changes**
-   - Implement efficiency and reliability improvements
-   - Run tests
-   - Commit: `chore: apply review round 2 feedback`
-
-7. **Review Round 3 (Overall Quality)**
-
-   | Dimension | Check |
-   |-----------|-------|
-   | Readability | Clear naming? Functions < 40 lines? |
-   | Dead Code | Unused code, commented blocks, stale TODOs? |
-   | Formatting | Consistent indentation, spacing, line length? |
-   | Documentation | JSDoc complete? Complex logic commented? |
-   | Types | TypeScript strict? No `any` types? |
-
-   - Document as "Review Round 3 — Overall Quality"
-
-8. **Apply Round 3 Changes**
-   - Final polish
-   - Run tests
-   - Commit: `chore: apply review round 3 feedback`
-
-### Phase C: Finalize
-
-9. **Build, Verify, Merge**
-   - `npm run build` — must pass
-   - `npm test` — must pass
-   - Update PR description with 3-round review summary
-   - Squash merge to main
-   - Delete feature branch
-
-## Checklist
-
-- [ ] Feature branch created with correct naming convention
-- [ ] Unit tests written next to source files (1:1 ratio)
-- [ ] All tests passing before PR creation
-- [ ] Review Round 1 completed (Refactor & Consistency)
-- [ ] Round 1 changes applied and committed
-- [ ] Review Round 2 completed (Efficiency & Reliability)
-- [ ] Round 2 changes applied and committed
-- [ ] Review Round 3 completed (Overall Quality)
-- [ ] Round 3 changes applied and committed
-- [ ] Build passes (`npm run build`)
-- [ ] Full test suite passes (`npm test`)
-- [ ] PR description updated with review summaries
-- [ ] Squash merged to main
-
-## Exceptions
-
-- **Hotfixes**: Critical production fixes may skip Rounds 2-3 but must still have
-  Round 1 review and tests. Use `hotfix/` branch prefix.
-- **Documentation-only changes**: Pure .md file changes can skip all review rounds.
-- **Config/dependency updates**: Can skip Rounds 2-3 if change is mechanical
-  (e.g., version bump). Still needs Round 1 review.

package/config/templates/dev-fullstack/norms/quality-gates.md

@@ -1,62 +0,0 @@
-# Quality Gates
-
-**Trigger**: before_deploy
-**Applies to**: *
-**Version**: 1.0.0
-
-## Overview
-
-Before any code is deployed (to staging or production), all quality gates must pass.
-No exceptions. These gates are enforced automatically via the verification pipeline
-and manually verified by the team leader.
-
-## Steps
-
-1. **TypeScript Compilation**
-   - Run: `npm run build`
-   - Requirement: Zero errors, zero warnings
-   - Covers: All components (backend, frontend, CLI, MCP server)
-
-2. **Type Checking**
-   - Run: `npm run typecheck` (or `npx tsc --noEmit`)
-   - Requirement: No type errors in any source file
-   - Strict mode must be enabled
-
-3. **Unit Tests**
-   - Run: `npm test`
-   - Requirement: 100% pass rate
-   - Minimum 80% code coverage for new code
-
-4. **Linting**
-   - Run: `npm run lint`
-   - Requirement: No errors (warnings acceptable with justification)
-
-5. **Integration Verification**
-   - Backend health: `curl http://localhost:3000/health` returns 200
-   - MCP server health: `curl http://localhost:3001/health` returns 200
-   - CLI smoke test: `npx crewly start --no-browser` starts without errors
-
-6. **Code Quality**
-   - No `console.log` in production code
-   - No commented-out code blocks
-   - No TODO comments without linked GitHub issues
-   - All functions have JSDoc documentation
-
-## Checklist
-
-- [ ] `npm run build` — zero errors
-- [ ] `npm run typecheck` — zero type errors
-- [ ] `npm test` — 100% pass rate
-- [ ] `npm run lint` — no errors
-- [ ] Backend health check passes
-- [ ] MCP server health check passes
-- [ ] No console.log in production code
-- [ ] No commented-out code
-- [ ] All new functions have JSDoc
-
-## Exceptions
-
-- **Staging-only deploys** for testing may proceed with lint warnings if time-critical,
-  but must be cleaned up before production deploy.
-- **Emergency hotfixes** must still pass Steps 1-4 (build, typecheck, tests, lint).
-  Steps 5-6 can be verified post-deploy.

package/config/templates/research-analysis/norms/research-methodology.md

@@ -1,77 +0,0 @@
-# Research Methodology Standards
-
-**Trigger**: always
-**Applies to**: *
-**Version**: 1.0.0
-
-## Overview
-
-All research output from this team must follow rigorous methodology standards.
-These norms are always active — they govern how we collect, analyze, and present
-information. Adherence to these standards is what distinguishes our analysis from
-generic content.
-
-## Research Framework
-
-### Phase 1: Scope Definition
-- Define the research question precisely (what, why, for whom)
-- Set clear boundaries (time period, geography, industry scope)
-- Identify key metrics and success criteria
-- Document assumptions and known biases upfront
-
-### Phase 2: Data Collection
-- **Primary sources first**: Official documentation, changelogs, GitHub repos,
-  API docs, SEC filings, press releases
-- **Secondary sources**: Reputable tech publications (minimum 2 independent sources
-  for any claim), analyst reports, conference talks
-- **Tertiary sources**: Social media, forums, blog posts (corroborate with primary
-  or secondary before citing)
-- **Never cite**: Anonymous Reddit posts, unverified tweets, or AI-generated
-  summaries as primary evidence
-
-### Phase 3: Analysis
-- **Quantitative**: Use specific numbers, percentages, and dates — not vague qualifiers
-- **Comparative**: Always benchmark against at least 2 competitors or alternatives
-- **Temporal**: Note when data was collected; flag anything older than 3 months
-- **Contradictory evidence**: Actively seek and document contradicting data points.
-  Acknowledge limitations rather than ignoring inconvenient evidence
-
-### Phase 4: Synthesis
-- Lead with conclusions, then support with evidence (inverted pyramid)
-- Separate facts from opinions — clearly label recommendations
-- Provide confidence levels: High (3+ independent sources), Medium (2 sources),
-  Low (single source or inference)
-- Include "So what?" — every finding must connect to an actionable recommendation
-
-## Quality Standards
-
-| Standard | Requirement |
-|----------|-------------|
-| Source minimum | 3+ independent sources per major claim |
-| Recency | Data from within last 6 months (flag older data) |
-| Cross-reference | Every quantitative claim verified by 2+ sources |
-| Contradictions | Must be acknowledged and discussed |
-| Confidence labeling | High/Medium/Low for each major finding |
-| Actionability | Every section ends with recommendation(s) |
-
-## Checklist
-
-- [ ] Research question clearly defined
-- [ ] Scope and boundaries documented
-- [ ] Assumptions and biases acknowledged
-- [ ] 3+ independent sources for major claims
-- [ ] Primary sources prioritized
-- [ ] All data within 6 months (older data flagged)
-- [ ] Quantitative claims cross-referenced
-- [ ] Contradictory evidence addressed
-- [ ] Confidence levels assigned
-- [ ] Findings connected to actionable recommendations
-- [ ] Analysis distinguishes facts from opinions
-
-## Exceptions
-
-- **Rapid-response analysis** (e.g., breaking security incident): May proceed
-  with fewer sources but must be clearly labeled "Preliminary Analysis" and
-  updated within 48 hours with full sourcing.
-- **Internal brainstorming documents**: May relax sourcing requirements but
-  must still distinguish speculation from fact.

package/config/templates/research-analysis/norms/source-citation.md

@@ -1,85 +0,0 @@
-# Source Citation Standards
-
-**Trigger**: always
-**Applies to**: *
-**Version**: 1.0.0
-
-## Overview
-
-Proper citation is non-negotiable for research integrity. Every factual claim,
-statistic, and direct quote must be attributed to its source using the format
-below. These standards apply to all research output — reports, briefings,
-competitive analyses, and strategy documents.
-
-## Citation Format
-
-### Inline Citations
-Use numbered references in square brackets within the text:
-
-```
-Crewly's PTY isolation model prevents lateral movement between agents [1],
-unlike OpenClaw's shared-process architecture which exposed 135,000+ instances
-to the ClawHavoc attack [2][3].
-```
-
-### Reference List
-At the end of every document, include a numbered reference list:
-
-```
-## References
-
-[1] Crewly Architecture Docs, "PTY Isolation Model", v1.3.34, March 2026.
-    Source: specs/project.md (Primary — project documentation)
-
-[2] SecurityWeek, "OpenClaw Vulnerability Exposes Thousands of AI Agents",
-    March 5, 2026. URL: [link] (Secondary — tech publication)
-
-[3] CVE-2026-0104, NIST National Vulnerability Database.
-    URL: [link] (Primary — official vulnerability record)
-```
-
-### Citation Components
-Each reference must include:
-1. **Author/Organization** — Who published it
-2. **Title** — What was published
-3. **Date** — When (month + year minimum)
-4. **Source type** — Primary, Secondary, or Tertiary
-5. **URL or location** — Where to verify
-
-## Source Credibility Tiers
-
-| Tier | Source Type | Reliability | Use For |
-|------|-----------|-------------|---------|
-| **Tier 1 (Primary)** | Official docs, GitHub repos, CVE records, SEC filings, press releases | Highest | Core claims, architecture facts, vulnerability data |
-| **Tier 2 (Secondary)** | Major tech publications (Ars Technica, SecurityWeek, The Verge), analyst reports, peer-reviewed papers | High | Market data, trend analysis, expert opinions |
-| **Tier 3 (Tertiary)** | Blog posts, conference talks, podcast transcripts, social media from verified accounts | Medium | Supporting evidence, community sentiment, anecdotes |
-| **Tier 4 (Unreliable)** | Anonymous posts, unverified social media, AI-generated content, SEO spam sites | Do Not Use | Never cite as evidence |
-
-## Verification Process
-
-1. **Can you access the source directly?** If not, find an accessible alternative
-2. **Is the source independent?** Avoid circular citations (A cites B cites A)
-3. **Is the date current?** Flag sources older than 6 months
-4. **Does the claim match the source?** Re-read the actual text — don't paraphrase beyond what it says
-5. **Is there a counter-source?** Seek at least one opposing viewpoint for controversial claims
-
-## Checklist
-
-- [ ] Every factual claim has an inline citation [N]
-- [ ] Reference list included at document end
-- [ ] Each reference has: author, title, date, source type, URL
-- [ ] No Tier 4 sources used as evidence
-- [ ] All URLs/locations are accessible and correct
-- [ ] No circular citations
-- [ ] Sources older than 6 months are flagged
-- [ ] Claims accurately reflect source content
-- [ ] Counter-sources acknowledged for controversial claims
-
-## Exceptions
-
-- **Common knowledge** (e.g., "TypeScript is a superset of JavaScript") does not
-  need citation.
-- **Internal team decisions** cited by meeting date and participants do not need
-  external verification.
-- **Preliminary analysis** may use fewer citations but must be clearly labeled
-  and updated within 48 hours.

package/config/templates/social-media-ops/norms/engagement-rules.md

@@ -1,35 +0,0 @@
-# Engagement Rules
-
-**Trigger**: always
-**Applies to**: *
-**Version**: 1.0.0
-
-## Overview
-
-Rules for interacting with community members, handling feedback, and managing brand reputation across social platforms.
-
-## Steps
-
-1. **Respond within SLA** — Acknowledge all direct mentions, DMs, and comments within 4 hours during business hours. Mark as seen even if a full response requires research.
-2. **Match tone to platform** — Twitter: concise and casual. LinkedIn: professional. Reddit: authentic and technical. Adjust formality accordingly.
-3. **Be helpful, not promotional** — Prioritize providing value. Answer questions directly. Share resources. Only mention the product when genuinely relevant to the question.
-4. **Handle criticism constructively** — Thank the person for feedback. Acknowledge valid points. Offer to take the conversation to DM for detailed issues. Never argue publicly.
-5. **Escalate sensitive issues** — If a post involves legal claims, security vulnerabilities, or potential PR crisis, escalate to team lead immediately before responding.
-6. **Credit community contributions** — When sharing community content, always credit the original creator. Ask permission before reposting.
-7. **Log interactions** — Record notable feedback, feature requests, and bug reports for the product team.
-
-## Checklist
-
-- [ ] Response is within 4-hour SLA
-- [ ] Tone matches the platform norms
-- [ ] Response provides value (not just promotional)
-- [ ] Negative feedback handled without defensiveness
-- [ ] Sensitive topics escalated before public response
-- [ ] Community creators credited when their content is shared
-- [ ] Notable feedback logged for product team review
-
-## Exceptions
-
-- **Spam or bot accounts** — Do not engage. Block/report as appropriate.
-- **Abusive messages** — Do not respond. Screenshot for records and block if needed.
-- **After-hours mentions** — Respond next business day. Automated acknowledgment is acceptable.

package/config/templates/social-media-ops/norms/posting-schedule.md

@@ -1,43 +0,0 @@
-# Posting Schedule
-
-**Trigger**: always
-**Applies to**: *
-**Version**: 1.0.0
-
-## Overview
-
-Guidelines for content publishing frequency, timing, and platform-specific rules. Ensures consistent presence without audience fatigue.
-
-## Steps
-
-1. **Check content calendar** — Before creating content, review the current week's posting schedule to avoid duplicate topics or over-posting.
-2. **Select optimal posting time** — Use platform-specific peak engagement windows (see table below).
-3. **Respect cooldown periods** — Maintain minimum intervals between posts on the same platform.
-4. **Adapt to time zones** — Target primary audience time zones. Default: US Pacific (PT) for tech audiences.
-5. **Queue, don't rush** — If content is ready outside posting windows, queue it for the next optimal slot rather than posting immediately.
-6. **Track post performance** — After posting, monitor engagement for 24 hours and note patterns for future optimization.
-
-### Platform Timing Guidelines
-
-| Platform | Posts/Week | Best Times (PT) | Cooldown |
-|----------|-----------|-----------------|----------|
-| Twitter/X | 5-7 | 9-11 AM, 1-3 PM | 3 hours |
-| LinkedIn | 2-3 | Tue-Thu 8-10 AM | 24 hours |
-| Reddit | 1-2 | Mon/Wed 10 AM-12 PM | 48 hours |
-| Blog | 1 | Tuesday 10 AM | 7 days |
-| Product Hunt | As needed | Tuesday 12:01 AM PT | N/A |
-
-## Checklist
-
-- [ ] Content calendar reviewed before posting
-- [ ] Posting time falls within platform's peak window
-- [ ] Cooldown period respected since last post on same platform
-- [ ] Content adapted for target platform format and tone
-- [ ] No more than 2 posts per platform per day
-- [ ] Hashtags/tags relevant and not excessive (max 5 per post)
-
-## Exceptions
-
-- **Breaking news or announcements** may be posted outside normal windows.
-- **Community responses** (replies, comments) are exempt from cooldown rules.
-- **Event-driven content** (product launches, conference live-tweets) follows event timing.