Muhammad Zaeem Khan

1. 1. Deep modules: a lot of behaviour behind a small interface, so callers learn little and get a lot.
2. 2. Whole interface: not just types, but invariants, ordering, error modes, configuration and performance a caller must know.
3. 3. Deletion test: if removing a module makes complexity vanish, it was a pass-through and goes.
4. 4. Real seams only: one implementation is a hypothetical seam; abstraction is added only when two actually vary.
5. 5. Testable by design: dependencies passed in, results returned, no hidden side effects.
6. 6. Test through the interface: if tests have to reach past it, the module is the wrong shape.
7. 7. Design it twice: several radically different interfaces sketched in parallel and compared before choosing.
8. 8. Locality: changes, bugs and knowledge concentrate in one place. Fix once, fixed everywhere.

Rule: no abstraction layer without two real implementations behind it.

1. 1. Stable contracts: endpoints, types and module boundaries designed so existing clients do not break.
2. 2. Retry-safe calls: the idempotency key comes from the intent, not the attempt, so a retry never charges twice.
3. 3. Atomic claims: no check-then-act sequences, because the gap between them is a race condition.
4. 4. Loud mismatches: the same key with a different payload fails instead of replaying the first response.
5. 5. Three outcomes: success, failure and unknown; intent is recorded before the call, so a crash leaves evidence.
6. 6. Shared vocabulary: domain terms are checked against a project glossary as they are used.
7. 7. Decision records: written only when a choice is hard to reverse, surprising, and a genuine trade-off.
8. 8. Match conventions: docs, changelog and API style follow what the codebase already does.

1. 1. Layered tokens: base values, semantic roles and component tokens kept as separate layers.
2. 2. Brand as source: brand guidelines generate the tokens directly instead of being restated by hand.
3. 3. Full component spec: variants, states, props, ARIA roles, keyboard behaviour and tokens used, per component.
4. 4. State coverage: every interactive state is defined up front, not discovered in QA.
5. 5. Consistency audit: existing UI scanned for drift, with each fix pointed to a file and line.
6. 6. Default-look flags: templated tells like purple-to-blue gradients and purposeless glass effects are called out.
7. 7. Handoff-ready: tokens map straight into CSS variables and Tailwind theme config.

Rule: the check fails if a hardcoded hex, rgb or pixel value appears in component code.

1. 1. Reference-backed choices: styles, palettes, fonts and UX rules pulled from a curated catalogue, not improvised.
2. 2. No fabrication: if the catalogue has no match, it says so instead of inventing one.
3. 3. Freshness dates: manually verified references expire after 365 days, unreviewed ones after 90.
4. 4. One master document: the whole design system lives in a single file developers and agents can both follow.
5. 5. No silent overwrite: an existing design document is never replaced without explicit confirmation.
6. 6. Tunable rules: constraints scale with explicit settings for layout variance and density.
7. 7. Platform traps: known failures, such as full-screen sections jumping on iOS Safari, are covered in the spec.

1. 1. Direction before code: a design plan is agreed before any interface is written.
2. 2. AI-default check: compared against known generated looks: cream with terracotta, near-black with one neon accent, identical rounded cards.
3. 3. Automated tell scan: flags grey text on colour, decorative glows and em-dash overuse; if it cannot run, the report says so.
4. 4. Evidence-first scoring: judged against Dieter Rams' ten principles using measurements: contrast ratios, spacing, JavaScript weight.
5. 5. Committed verdict: every critique ends in a decision and a concrete plan, not a list of opinions.
6. 6. Layout defects: six-line wrapped headings, dead grid cells, filler labels like "SECTION 01", invisible button text.
7. 7. Copy and placeholders: no "Elevate", "Seamless" or "Unleash", and no John Doe or Acme Corp.
8. 8. Mobile collapse: overlapping layouts simplify below 768px to avoid touch-target conflicts.

Rule: evidence gatherers never score; the verdict is computed from the scorecard.

1. 1. Image, then code: the look is generated as a reference, analysed in detail, then built to match.
2. 2. One image per section: each page section gets its own uncropped concept, because cropping destroys spacing accuracy.
3. 3. Variety gate: a set is rejected if one anchor repeats more than twice or one background style more than three times.
4. 4. Code over pixels: where real code and a generated image disagree, the code wins.
5. 5. No fake logos: if a real logo is not available, work stops and asks rather than inventing one.
6. 6. Brand board: logo, construction, colour, typography and real-world applications each get an assigned panel.
7. 7. Subtract on revision: the first draft is never final, and the second pass can only remove.
8. 8. Reproducible output: seeded generation, so any concept can be recreated exactly.

Rule: nothing is reported as exported until the file actually exists.

1. 1. Picture or prose: a diagram only when a reader learns more from it than from text, a table or a list.
2. 2. Right diagram type: architecture, sequence, data flow, state machine, ER model, swimlane or timeline, matched to the question.
3. 3. Complexity budget: a node cap per diagram type, such as 9 nodes for architecture and 8 visible foreign keys for a schema.
4. 4. Clean connectors: no diagonal lines, and no labels sitting on top of lines.
5. 5. Fits every screen: no horizontal scroll at three named resolutions, and no hiding overflow to fake a pass.
6. 6. Honest validation: pass or fail comes from the renderer itself, never a hardcoded "success".
7. 7. Frozen snapshot: the delivered file is fingerprinted, so what was reviewed is exactly what ships.
8. 8. Human eyes last: automated browser checks never stand in for a person actually looking at it.

1. 1. Inventory first: record what is already installed before changing anything.
2. 2. Few questions, one confirmation: two questions, one confirmation, then changes apply without further prompting.
3. 3. Independent verification: a separate second check confirms the install; no "ready" on a dry run, cancellation or unverifiable state.
4. 4. No pretend parity: Claude and Codex are configured to what each really supports; guardrails are never assumed to carry across.
5. 5. No installer overreach: missing tools are reported as optional, and only what the workflow needs gets installed.
6. 6. Right checkout: fixes land only in a writable checkout, and a different target is diagnosed before it is touched.
7. 7. Secrets stay private: secret prompts are typed by the human in their own terminal; stored tokens get owner-only file permissions.
8. 8. Locked-down access: channels that feed outside messages to the agent end on an explicit allowlist, never an open pairing mode.

1. 1. Written quality bar: coverage, performance and test rules written down as a contract, with numbers the client chose.
2. 2. Weakening watch: every diff is checked for five moves: threshold lowered, test skipped or deleted, checker silenced, throwing stub, new exception.
3. 3. Outside opinion: at least one check the agent cannot influence; ratchets hold today's real number, not an invented target.
4. 4. Facts before edits: file edits are blocked until the agent presents concrete findings, such as callers, existing patterns and data formats.
5. 5. Dangerous command blocks: force-push, skipped hooks or tests, committed secrets and destructive database commands are refused by the harness itself.
6. 6. Injection boundary: access or permission changes are refused when the request arrived through an incoming message, and approvals are never auto-picked.
7. 7. Config cleanup: stale hooks, servers and add-ons are removed one confirmation at a time, soft-deleted first.
8. 8. Clean shutdown: long-running agent modes stop in the right order, clearing runtime state while keeping the plans.

1. 1. Compaction at milestones: context is condensed at logical phase boundaries, not at an arbitrary automatic cutoff.
2. 2. Real signal: triggered by actual context size, not tool-call count, since a few large reads can fill it in three calls.
3. 3. What survives: known list of what survives condensing; the task list is no longer assumed to persist.
4. 4. Context headroom: bloated or duplicated instructions are found and trimmed, and instruction files over 400 lines are flagged.
5. 5. Persistent memory: project rules and session state reload at every session start through deterministic scripts, not the model's recollection.
6. 6. Proven loading: any new kind of memory is verified by confirming it actually appears in startup context.
7. 7. Secrets out of memory: tokens are kept out of chat, command arguments and logs.

1. 1. Baseline first: past runs are mined for a baseline before any instruction or rule changes.
2. 2. Noise floor: run-to-run variation is measured so a random swing is not mistaken for improvement.
3. 3. Bar set in advance: the success bar is fixed before any change exists; no tuning happens without a test harness.
4. 4. Adversarial audit: instructions are audited adversarially, then cut in measured passes until the bar clears.
5. 5. Failures become hooks: observed bad behaviour is turned into an enforced rule that blocks the action in future sessions.
6. 6. Independent hooks: each hook works alone, since hooks run in parallel, in no fixed order, blind to each other.
7. 7. Block or warn: each rule is clearly a hard block or a warning, and a block's reason goes back to the agent.

Rule: no change counts as a win until it clears the pre-registered bar above the noise floor.

1. 1. Isolated workspace: each feature gets its own Git worktree and branch, so work in progress never touches main.
2. 2. Ignored before created: confirm the workspace folder is Git-ignored before creating it, so it can never be committed.
3. 3. Clean baseline: tests pass before any change, so every later failure is provably new.
4. 4. Fail closed: if isolation cannot be set up, work stops rather than quietly continuing in place.
5. 5. Shared repo harness: context, rules, tools and standards set up once, so every human and agent inherits them.
6. 6. Extend, never overwrite: existing project docs and config are extended in place, never clobbered by fresh templates.
7. 7. Boundaries enforced in CI: each package is reachable only through its entry points, checked on every build.
8. 8. Secrets traced: every secret configured is traced to the CI step that actually uses it.

Rule: a Linux container never counts as testing macOS or Windows behaviour.

1. 1. Red first: no implementation code until a test fails for the right reason.
2. 2. Code before test is deleted: code written ahead of its test is thrown out, not retrofitted.
3. 3. Prove-It for bugs: reproduce the bug with a failing test, then fix it.
4. 4. Real red only: a compile error or missing import is not a failing test; it must fail on behaviour.
5. 5. Test-double order: real over fake, fake over stub, stub over mock, with mocks only in narrow cases.
6. 6. Test outcomes, not calls: assert what the system produced, not which internal methods it called.
7. 7. Mutation check: break the code on purpose to confirm the test notices.
8. 8. Old failures surfaced: tests that were already broken are reported, never quietly "fixed" to pass.

Rule: 80%+ coverage across unit, integration and E2E tests; new integrations ship behind a flag, and with the flag off the app behaves exactly like main.

1. 1. Non-trivial trigger: new branching logic, a crossed module or service boundary, or a property the compiler cannot verify (thread safety, idempotence, ordering).
2. 2. Fresh-eyes review: a reviewer with no shared context gets the code and the contract, but not the author's claim, so it cannot just agree.
3. 3. Findings ranked: misread contract first, then actionable bugs, then trade-offs; noise is discarded.
4. 4. Cross-model check: Codex reviews in a read-only sandbox, so the reviewed content cannot make it change anything.
5. 5. Doubt theatre alarm: two cycles of findings with nothing actionable means validating, not doubting, so it stops.
6. 6. Official docs only: framework code is grounded in current official docs, not Stack Overflow, blogs, AI summaries or memory.
7. 7. Version-matched: the installed version is read from dependency files, and the exact doc section is cited.
8. 8. Say when unverified: code without a doc source is marked UNVERIFIED; if docs conflict with existing code, both options are shown.

Rule: at most 3 doubt cycles on one decision, then it escalates to a human.

1. 1. Animate or not: motion is added only when it helps the user follow a change.
2. 2. Navigation map first: every route and transition is written down before code, then each path is verified.
3. 3. Silent UI failures: a symptom-named checklist, such as an element that teleports instead of gliding, with honest notes on what cannot be fixed.
4. 4. Authorization in code: a schema checks shape, not permissions; the handler enforces its own auth and business rules.
5. 5. Page content untrusted: anything read from a page is treated as input, with its origin recorded.
6. 6. Zero checks is not a pass: an audit reporting "0 checks run" is a failure, not a clean result.
7. 7. Real build every time: the production build runs on every change; skipping it is not allowed.
8. 8. Quality bar from real bugs: every review criterion traces to a defect actually found, not to taste.

Rule: work is "done" only when every completion condition holds; otherwise it is reported as blocked.

1. 1. Severity-ranked rules: React Native and Expo anti-patterns graded by impact, with list performance treated as critical.
2. 2. Fast long lists: list components built for large data sets, not the default that stutters.
3. 3. Native navigation: native stack and tab navigators over JavaScript re-implementations.
4. 4. One image pipeline: a single optimised, cached image component used everywhere.
5. 5. Native touch feedback: modern press handling instead of legacy touch wrappers.
6. 6. Exact asset scales: icons generated at 1x, 2x and 3x with correct catalog metadata, not hand-resized.
7. 7. Failed assets stop the build: a failed icon conversion is an error, never a warning to scroll past.
8. 8. Safe state (Flutter): null safety, immutable state and sealed types, so impossible states fail to compile.

1. 1. Preflight gate: environment and connection checks must all pass before any work starts.
2. 2. Small data first: the pipeline must pass on a small sample before it touches real data.
3. 3. Traceable numbers: every calculated value links back to its source; the validator fails delivery otherwise, with warnings promoted to errors.
4. 4. ORM traps: bulk updates return a count not rows and skip auto timestamps, dev migrations can reset the database, soft-deleted rows can leak.
5. 5. Serverless connections: pooling sized so serverless functions do not exhaust the database.
6. 6. API mapping: undocumented APIs are traced by running each flow twice with different inputs, revealing which parts are parameters.
7. 7. Auth by omission: find which headers actually matter by removing them one at a time; credentials stay out of recordings.
8. 8. Untrusted inputs: scraped or third-party data is treated as untrusted, and units and precision are looked up, never assumed.

1. 1. Memory is stale: API shapes Claude might recall wrongly are checked against current docs, such as deprecated parameters now rejected.
2. 2. Right provider first: before touching code, confirm which SDK the project actually uses; a mismatch stops the work.
3. 3. Version gate: installed package and runtime versions are checked; preview and stable APIs are never mixed.
4. 4. Cleanup is not migration: removing deprecated calls never turns into an unrequested major-version upgrade.
5. 5. Discovery before code: deployment model, auth and framework are settled before any scaffolding.
6. 6. Known silent failures: each anti-pattern paired with its exact symptom, such as a widget that renders blank because a CDN import is blocked.
7. 7. Usable by a model: AI tool integrations must pass ten evaluation questions that are independent, read-only, realistic, verifiable and stable.
8. 8. Runtime limits respected: code checked against the platform's real limits, finishing with type-check and lint.

Rule: clarifying questions come before design, and convention findings under 80% confidence are dropped.

1. 1. Human or agent test: if a mistake is detectable and reversible automatically, an agent does it; otherwise a human decides.
2. 2. Parallel safety check: tasks run in parallel only if they share no files or state; a write outside a task's files aborts the wave.
3. 3. Fresh context per task: each sub-agent gets a purpose-built brief, never the whole session history.
4. 4. Progress ledger: a plan-scoped record of what is done, so work resumes rather than restarts.
5. 5. Circuit breakers: a task stops and escalates after five review rounds; a lane halts after three failed repairs.
6. 6. Crash-safe pipelines: repeatable pipelines resume from a journal after a crash, never redoing finished steps.
7. 7. Approvals fail closed: a missing or unreadable approval means stop, not proceed.
8. 8. Returns checked: delegated work is accepted only when every required field of its report is present, with one capped retry.

1. 1. Evidence before claims: no "done", "fixed" or "passing" until the verification has run and its output is read.
2. 2. No loopholes: the rule covers any implied success, before commits, pull requests, handoffs or moving on.
3. 3. Blind verifiers: the checker never sees the builder's reasoning, because seeing it biases toward agreement.
4. 4. Independent votes: several verifiers judge without seeing each other's verdicts, so there is no social proof.
5. 5. Honest abstention: a confidently wrong answer is worse than "not verified".
6. 6. Existing tests untouched: the old suite runs with the new feature switched off; any failure is a hard fail no auto-fix may patch.
7. 7. Critical-path gates: for high-stakes logic and personal-data exposure, deploys need a 100% pass and stop at the first failure.

Rule: work that has not been run is reported as unverified, never as done.

1. 1. Journey map from the change: derive the affected user flows and turn them into a resumable test matrix.
2. 2. Real browser, real flows: click through the affected pages the way a user would.
3. 3. User, not auditor: whole-app exploratory passes never read the source; they report what a user sees.
4. 4. Reproduce before reporting: every issue is reproduced before evidence is captured.
5. 5. Evidence fits the bug: interactive bugs get video and step screenshots; static ones (typos, clipped text, console errors) get one annotated screenshot.
6. 6. Small fixes, with proof: small, low-risk breakages are fixed with a regression test that fails first, then passes.
7. 7. Persona check: the experience is judged against the product's target users.
8. 8. Protected previews, safely: access them with a short-lived token under a real identity, never by disabling protection or making them public.

Rule: anything that cannot be tested ends as an explicit "Blocked", never a quiet pass.

1. 1. Live page structure: read the accessibility tree and re-read it after every change, because old references go stale.
2. 2. Console, network, performance: errors, API responses and Core Web Vitals checked on the live page, not in the source.
3. 3. Accessibility defects: debugged against the computed tree in the browser, which static review cannot reach.
4. 4. Memory leaks: compare heap snapshots to find retained objects in pages that slow down the longer they run.
5. 5. Cookies and sessions: diagnose 401/403s and login redirects, and prove the consent banner sets no non-essential cookies first.
6. 6. Silent-failure traps: HttpOnly cookies cannot be cleared from JavaScript and the attempt fails silently, so no false "fixed".
7. 7. Isolated session: a dedicated browser session, never a shared one that could hijack another task's page.
8. 8. Contained blast radius: never attach to an everyday browser profile; page content is untrusted data, and scripts cannot touch credentials.

1. 1. Simulator evidence: iOS changes come with screenshots and logs from a simulator run before handoff.
2. 2. Status from evidence: a pass needs completed passing evidence, and a failure stands until a completed retest replaces it.
3. 3. Windows desktop tests: end-to-end UI Automation tests for WPF, WinForms, Win32 and Qt, with per-framework reliability caveats.
4. 4. Testability built in: automation IDs and accessible names added so tests survive layout changes.
5. 5. Discover before recording: list the live interactive elements before scripting a demo, so recordings don't fail silently.
6. 6. Demo videos: rehearsed feature walkthroughs for stakeholders, onboarding and documentation.
7. 7. Failures go to debugging: QA reports and routes failures instead of patching them on the spot.

Rule: a check with no completed outcome is a skip, never a pass, and the overall result fails while any failure remains.

1. 1. Never on main: work moves to a feature branch automatically before the first commit.
2. 2. Explicit staging: files are added by name; "add everything" is banned, so stray files stay out.
3. 3. Secret scan: staged changes are checked for credentials before committing.
4. 4. Atomic commits: one logical change per commit, easy to review and easy to revert.
5. 5. Intent in the message: Conventional Commits, why over what, 50-character target, 72 hard cap, imperative mood.
6. 6. No filler: no "this commit does X"; credit goes in a trailer, not prose.
7. 7. Isolated parallel work: each parallel agent gets its own Git worktree, so no one overwrites anyone.
8. 8. Versioning: trunk-based flow, semantic versions and a maintained changelog.

1. 1. Written description: the PR body explains what changed and why, not a raw dump.
2. 2. The right PR: across forks and owners, the existing PR is identified deterministically before anything is updated.
3. 3. Empty is not "none": an empty lookup is distinguished from an unknown result, since some queries return nothing silently.
4. 4. Watched to merge-ready: the open PR is monitored and reacts to review comments, CI failures and base-branch movement.
5. 5. No double actions: every change to the PR is claimed, performed, then confirmed, so nothing happens twice.
6. 6. Consolidate scattered work: work spread across branches gets a read-only comparison and one agreed plan before any merge.
7. 7. Deliberate integration: once tests pass, merge, PR, keep or discard is an explicit choice; discarding requires typing "discard".

1. 1. Probe without side effects: deployment state is checked with truly read-only commands, since some "read" commands silently link or change the project.
2. 2. Tokens never in arguments: never pass a token as a command-line argument: it lands in shell history and process listings.
3. 3. Token lookup order: environment first, then the project's env files, and only then ask a human.
4. 4. Secret sanitizer gate: before a private project goes public, a sanitizer pass strips secrets, and any critical finding fails the release.
5. 5. One version everywhere: the version string lands identically in every manifest, confirmed by a search across the repo.
6. 6. Publishing stays human: the final package publish is a human action, followed by a check that the exact version and latest tag are live.
7. 7. Safe re-runs: re-running the release repeats nothing already done and never asks for the same approval twice.
8. 8. No assumed sandbox: a locally packaged tool treats every input as untrusted, even input from an AI, because nothing enforces its permissions.

Rule: any critical finding in the secret scan blocks the release, with three retries at most, and the sanitizer is never skipped.

1. 1. Pre-launch checklist: every production release goes through a launch checklist first, because every deployment carries risk.
2. 2. Staged rollout: release in stages, each with advance, hold or rollback thresholds per metric.
3. 3. Rollback ready: a written rollback plan exists before the deploy, not after something breaks.
4. 4. Go/no-go panel: code review, security audit and test review run in parallel and merge into one ship decision.
5. 5. Post-deploy smoke checks: endpoints, streaming connections, static assets, console errors and performance checked against numeric bands.
6. 6. Named blind spots: failures that basic checks miss, such as streaming connections that drop before the first heartbeat.
7. 7. Unskippable CI gates: pipeline quality gates cannot be bypassed, and rollback itself runs as an automated workflow.
8. 8. Automation inventory: which scheduled jobs, hooks and integrations are live, broken or redundant, backed by evidence.

1. 1. Shared product brief: one written brief covering ideal customer, category, positioning and customers' own words, used by every later piece.
2. 2. Forced dissent: decisions are debated by a simulated advisory panel with a mandatory dissenter, because agreement proves nothing.
3. 3. Disagreement map: every split names the underlying trade-off and the evidence that would settle it.
4. 4. Value metric: price is tied to the unit customers actually value.
5. 5. Tier design: good-better-best packaging checked against six pricing models and competitor benchmarks.
6. 6. Willingness to pay: tested with an established four-question price-sensitivity survey and ranked-choice methods, not guessed.
7. 7. Revenue scenarios: any price change comes with revenue scenarios and a migration plan for existing customers.
8. 8. Growth plan: a stage-by-stage plan from acquisition through activation, retention, revenue and referral.

1. 1. Seven separate passes: clarity, voice, so-what, proof, specificity, emotion and risk removal, each its own pass with a regression re-check.
2. 2. Plain over clever: benefits over features, customer language over company language, specifics over vague claims.
3. 3. Brief echoed back: audience, goal and key themes are confirmed before writing, with at most two rounds of questions.
4. 4. Don't-send gate: a press pitch goes out only if every readiness question passes; news angles must score at least 50 of 80.
5. 5. No smears: the villain is a broken system or norm, never a named competitor.
6. 6. Content mix: roughly 60/30/10 searchable, shareable and experimental topics.
7. 7. Headline options: ten title options before drafting, then several editing passes.
8. 8. Channel plan: owned, rented and borrowed channels planned across launch phases.

1. 1. Storyboard first: promo videos are planned as a beat sheet and reviewed before anything is rendered.
2. 2. Gated production: every step closes with a check, and key steps wait for the client's approval.
3. 3. Refuse bad inputs: captioning is refused for multi-speaker, subject-less, under-three-second or near-silent clips, where transcription invents words.
4. 4. Existing text check: footage is scanned one frame per second for burned-in text before captions are added.
5. 5. Audio on speech: sound problems are diagnosed from the speech itself, never ruled out from the silent gaps.
6. 6. Exact brand assets: logos and brand media are reused only on an exact match, never a lookalike.
7. 7. Platform limits verified: dimensions, frame rate, colours and duration are checked by a validator against each platform's limits.
8. 8. Borrow technique only: reference work is copied for technique, never for its creative.

1. 1. Answer extractability: pages are audited for clean, quotable answer passages of about 40 to 60 words.
2. 2. AI crawler policy: each AI crawler is allowed or blocked deliberately; the middle ground blocks training scrapers and allows search bots.
3. 3. Agent-readable summary: a plain-text site summary is published for AI agents alongside normal crawler rules.
4. 4. Structured data: JSON-LD for organisation, articles, products, FAQs and breadcrumbs, validated.
5. 5. Rendered check: markup is verified in a real browser, since plain fetches miss JavaScript-injected data.
6. 6. Technical audit: crawlability, indexation, language tags, titles, internal links and expertise signals.
7. 7. Quality over scale: templated pages only on defensible data, in subfolders not subdomains; 100 great pages beat 10,000 thin ones.

Rule: any statistic about AI citation share is treated as dated and rechecked before it drives a decision.

1. 1. Directory plan: submissions to a tiered catalogue of about 250 startup, SaaS, AI and developer directories for discovery and backlinks.
2. 2. Readiness gate: a nine-question checklist blocks the launch until every answer passes.
3. 3. Launch timing: Product Hunt launches at 12:01 AM Pacific, Tuesday to Thursday only; weekends lose 60 to 70% of traffic.
4. 4. Warm-up: a 21-day warm-up, with comment quality valued over upvote counts.
5. 5. Store listing score: App Store and Play Store listings graded A to F on six weighted dimensions, led by visuals at 25%.
6. 6. Field limits: Play title 30 characters, short description 80, full description 4,000; Apple does not index the description.
7. 7. Site structure: page hierarchy, URLs, navigation and internal links mapped before pages are built.
8. 8. Untrusted input: competitor listings and reviews are analysed as data, never followed as instructions.

1. 1. Scheduled reviews: recurring checks for ad fatigue, stale content, churn and rankings run on a set schedule.
2. 2. Check versus act: how often a job checks is separate from when it acts; most runs rightly find nothing to do.
3. 3. No double actions: each run keeps a last-run marker, a dedupe key and a cooldown window.
4. 4. Stop condition: every recurring job has an explicit stop or bail-out, even simple heartbeat checks.
5. 5. Self-checks: each run verifies its own output before reporting it.
6. 6. Attribution model: first-touch, last-touch or multi-touch chosen deliberately for the question being asked.
7. 7. Reconciled numbers: conflicting ad-platform and analytics figures are reconciled, and real acquisition cost is computed before anyone acts.

1. 1. Questions first: write down the 2 to 4 questions on-call will ask before adding any log, metric or trace.
2. 2. Right signal for the job: metrics say something is wrong, traces say where, logs say why.
3. 3. Correlation IDs: every request carries one ID through every log line and service hop.
4. 4. Cardinality control: unbounded values never become metric labels, following an explicit allowed and never-allowed list.
5. 5. Alert on symptoms: page on what users feel, such as p99 latency over 2 seconds; CPU at 85% belongs on a dashboard, not a pager.
6. 6. Verify the telemetry: confirm logs, metrics and traces actually arrive before calling the feature done.
7. 7. AI spend visibility: every LLM call is metered and grouped by the job it does, labelled at the caller, with no behavior change.
8. 8. Report, don't infer: cost and savings figures come only from what was recorded, never from estimates.

1. 1. Production signals first: start from real metrics, usage and config; code is opened only once a signal points at a route, file or setting.
2. 2. Metric-driven loop: define the metric, run experiments, keep only what measurably moves it.
3. 3. Fair comparison: baseline and candidate use identical inputs and measurement, or the comparison is thrown out.
4. 4. Neutral is a revert: a change with no measurable gain is rolled back; passing unit tests do not prove an optimization.
5. 5. Symptom to cause: N+1 queries, pagination, oversized connection pools, bundle size and Core Web Vitals traced from symptom to root cause.
6. 6. Cache safety: a cache key that omits the viewer serves one user's data to another; hot keys expiring under load get stale-while-revalidate or request coalescing.
7. 7. Fix order by impact: remove request waterfalls and bundle bloat before any micro-optimization.
8. 8. LLM cost control: route model calls by task complexity, cache system prompts over 1024 tokens, and fail fast on auth errors instead of retrying.

Rule: no source file is opened for tuning until a production signal points at it.

1. 1. Threat model per boundary: STRIDE applied at every trust boundary, with a mitigation for each threat.
2. 2. OWASP coverage: the OWASP Top 10 for the app, plus the OWASP LLM Top 10 for any AI feature.
3. 3. Verified findings only: several reviewers vote on each finding, and the verified label is computed from the votes, not asserted.
4. 4. Scan what changed: the whole repo, a branch, a pull request or a single commit, with findings turned into targeted patches.
5. 5. Three-tier permissions: always do, ask first, never do.
6. 6. Named traps: in-memory rate limiters, blindly forced dependency fixes, and server-side request forgery checks that can be raced.
7. 7. Reachability first: dependency alerts triaged by whether the vulnerable code is actually reachable, and low-signal findings discarded.
8. 8. Fail-closed controls: abuse checks verify on the server and fail closed; secrets are read from standard input, never from arguments.

1. 1. Stop-before-drafting list: some requests go to a human instead of a template, and on a trigger nothing is generated.
2. 2. Marked drafts: escalated output is clearly labelled for human review, and the escalation check is recorded for audit.
3. 3. Readiness score: production readiness scored 0 to 100 into four bands (Blocked, Risky, Launchable with caveats, Strong), each tied to a ship decision.
4. 4. Evidence receipts: every score cites the evidence behind it, so nothing is graded on a hunch.
5. 5. Score caps: certain gaps cap the score, however good the rest looks.
6. 6. Data classification: personal and sensitive data classified, with access control and encryption to match.
7. 7. Tamper-proof audit trail: audit logs protected at the database level, for example with Postgres row-level security, so they cannot be edited.
8. 8. Leak vector sweep: six known ways sensitive data escapes are checked, plus a ten-item pre-deploy list.

Rule: a request that hits any of 40+ escalation triggers gets no templated reply; it becomes a draft for human review.

1. 1. Document the fix: each solved problem becomes a structured, searchable learning in the repo.
2. 2. Grounded in code: learnings are checked against the actual codebase, not built from a summary of a summary.
3. 3. Refresh stale notes: outdated, overlapping or superseded learnings are audited, and unverifiable is not treated as false.
4. 4. Feedback sweep: Slack and GitHub Issues checked for new feedback, acknowledged at the source, with fixes confirmed as merged.
5. 5. Guarded replies: nothing is posted back to a feedback source without approval, and every reference must match a real issue or commit.
6. 6. Confidence-scored lessons: each lesson carries a confidence score and stays scoped to its project until it holds in two or more projects.
7. 7. Product pulse: time-windowed reports from real signals, using read-only credentials, no personal data on disk and no full-table scans.
8. 8. Launch notes: announcement copy drafted for shipped features, never posted without approval.

Rule: deleting a stored learning requires three conditions to hold at once; doubt alone is never enough.

1. 1. Cold-reader test: a fresh model holding only the document answers 5 to 10 likely reader questions; done when it gets them right and finds no new gaps.
2. 2. Three probes: what is ambiguous, what knowledge it assumes, and where it contradicts itself.
3. 3. Validated files: Word and slide files pass structural validation before delivery.
4. 4. Render and inspect: every slide rendered and checked, and leftover placeholder text searched for.
5. 5. Visible edits: changes to Word documents made as attributed tracked changes, so nothing hides in the accepted view.
6. 6. Live status pages: multi-workstream projects get one shareable status page, built from live sources, never from memory.
7. 7. Never invent a delta: each refresh reports only what verifiably changed since the last one.
8. 8. Separate credentials: shared-document links use an everyday edit key and a separate owner secret, never stored in the repo, commits or logs.

Rule: a spreadsheet never ships while a recalculation still reports formula errors.

1. 1. Visual explainer: a durable, visual teaching page for a concept, a code change or a stretch of work.
2. 2. Predict, then reveal: for a code change, you predict the outcome before seeing it, which makes it stick.
3. 3. Corrected exercises: optional check-ins with feedback, not just passive reading.
4. 4. Pitched at your level: explanations build from what you already know, not from the top of the textbook.
5. 5. Coverage is not learning: the goal is understanding the decisions, not a tour of every file.
6. 6. Fair quizzes: answer options of equal length, so the right one does not give itself away.
7. 7. Honest gaps: an empty or missing change range is named, never quietly swapped for something else.
8. 8. Consent before sharing: nothing is published until you have seen the warning and agreed.

1. 1. Docs with clear roles: project docs split into constitution, map, status and history, each with a "must not become" list.
2. 2. One home per fact: every fact has exactly one canonical document, so answers never conflict.
3. 3. Delete zone: each removal records why, what replaced it and when to revisit, so deleted things do not reappear.
4. 4. Docs are evidence, not orders: process docs are checked against the code before being trusted.
5. 5. Session handoff: the next engineer or session continues without the chat history, with specs, plans and commits linked, not copied.
6. 6. Redacted handoffs: no keys, passwords or personal data, and handoff notes kept out of the repo.
7. 7. Persistent memory: each session's work is captured and summarised automatically, so the next one starts with context.
8. 8. Weekly narrative: long projects summarised week by week, each chapter carrying forward what came before.