Remove assistant-only repo docs

Author: sheeki03

.gitignore

@@ -5,6 +5,16 @@ native/target/
 *.node
 bun.lock
 yarn.lock
+package-lock.json
 .DS_Store
 .env
 .playwright-mcp/
+.factory/
+
+# Local AI/editor instruction files
+AGENTS.md
+CLAUDE.md
+GEMINI.md
+COPILOT.md
+.cursorrules
+.clinerules

AGENTS.md

@@ -1,82 +1,73 @@
 # Contributing to Schrute
 
-Thank you for your interest in contributing to Schrute!
+Thank you for contributing.
 
-## Getting Started
+## Prerequisites
 
-### Prerequisites
-
-- Node.js >= 22
+- Node.js 22 or newer
 - Git
+- Playwright Chromium: `npx playwright install chromium`
 
-### Setup
+## Setup
 
 ```bash
 git clone https://github.com/sheeki03/schrute.git
 cd schrute
 npm install
-npx playwright install chromium
 npm run build
 ```
 
-### Verify Setup
+## Verify Your Environment
 
 ```bash
-npx vitest run        # All tests should pass
-npx tsc --noEmit      # No type errors
-node dist/index.js doctor  # Health check
+npm run lint
+npx vitest run
+node bin/schrute.cjs doctor
 ```
 
-## Development Workflow
+## Development Expectations
 
-1. Create a feature branch from `main`
-2. Make your changes
-3. Run tests: `npx vitest run`
-4. Run type check: `npx tsc --noEmit`
-5. Submit a pull request
+- Keep changes focused. Prefer one feature or one fix per pull request.
+- Add or update tests for behavioral changes.
+- Update user-facing docs when behavior, flags, commands, or APIs change.
+- Route execution, browser, and skill behavior through the engine and existing repositories instead of adding side paths.
+- Keep error handling fail-closed. If an operation is unsafe or ambiguous, deny it and log the reason.
 
-## Code Style
+## Repo Hygiene
 
-- TypeScript strict mode
-- Fail-closed security: when in doubt, deny
-- Bare `catch` blocks must log the error (no silent swallowing)
-- Use `getLogger()` from `src/core/logger.ts` for logging
+- Do not commit local assistant/editor instruction files such as `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `COPILOT.md`, `.cursorrules`, or `.clinerules`.
+- Do not commit personal experiment artifacts or generated local assets unless they are intentionally part of the product.
+- Do not add package-manager lockfiles unless the project explicitly adopts one.
 
-## Testing
+## Testing Notes
 
-- Framework: vitest
-- Config objects in tests must include `daemon: { port: 19420, autoStart: false }`
-- Use the `makeTestConfig()` helper from `tests/helpers.ts`
-- Browser tests mock Playwright via `vi.mock('playwright')`
-- All tests must be deterministic (no timing-dependent assertions)
+- Tests use Vitest.
+- Prefer `makeTestConfig()` from `tests/helpers.ts` when a full config object is needed.
+- Browser-facing tests should mock Playwright unless the test is explicitly integration or E2E.
+- Keep tests deterministic. Avoid timing-sensitive assertions where possible.
 
-### Running Tests
+## Useful Commands
 
 ```bash
-npx vitest run                              # All tests
-npx vitest run tests/unit/config.test.ts    # Specific test
-npx vitest --watch                          # Watch mode
-npx vitest run --coverage                   # With coverage
+npm run build
+npm run lint
+npx vitest run
+npx vitest run tests/unit/engine.test.ts
+npx vitest --watch
 ```
 
-## Architecture Notes
-
-- **Engine boundary**: All browser/skill operations go through Engine. Never bypass.
-- **Policy boundary**: 9 security gates on every execution. Never skip gates.
-- **Daemon boundary**: CLI connects to daemon via UDS. No direct engine access from CLI.
-- **Storage boundary**: All data access through repositories. Never raw SQL.
+## Pull Requests
 
-## Pull Request Process
+Before opening a pull request:
 
-1. Ensure all tests pass
-2. Update documentation if needed
-3. Add tests for new functionality
-4. Keep PRs focused — one feature or fix per PR
-5. Write descriptive commit messages
+1. Run the relevant tests and type checks.
+2. Update documentation if the change affects how Schrute is used or operated.
+3. Review the diff for accidental local files or generated artifacts.
+4. Write a clear pull request description explaining the behavior change and validation performed.
 
-## Security
+## Security Issues
 
-If you discover a security vulnerability, please see [SECURITY.md](SECURITY.md) for responsible disclosure instructions. Do NOT open a public issue for security vulnerabilities.
+If you discover a security vulnerability, follow [SECURITY.md](SECURITY.md). Do not open a public issue for undisclosed security bugs.
 
 ## License
 

CLAUDE.md

@@ -10,7 +10,7 @@ Teach your AI a website once. After that, it can repeat the job much faster.
 
 Schrute is for repeated website tasks.
 
-It watches what happens in a real browser, learns the underlying network requests, and turns them into reusable tools. That means the first run can happen in the browser, but later runs can often skip the UI and go straight to the site's backend.
+It supports both paths: you can teach it by having it watch what happens in a real browser, or you can let it discover useful backend structure on its own when a site exposes it. Schrute can do either well, and it is up to you which path to use for a given site or task. Either way, it turns what it finds into reusable tools. That means the first run can happen in the browser, or you can start from direct discovery when that fits better, and later runs can often skip the UI and go straight to the site's backend.
 
 If you keep asking an AI to do the same website task over and over, Schrute is the layer that helps it stop starting from scratch every time.
 

CONTRIBUTING.md

@@ -2,55 +2,56 @@
 
 ## Reporting a Vulnerability
 
-If you discover a security vulnerability in Schrute, please report it responsibly.
+Please report security issues privately.
 
-### How to Report
+### Preferred Channel
 
-1. **GitHub Security Advisories** (preferred): Use [GitHub Security Advisories](https://github.com/sheeki03/schrute/security/advisories/new) to privately report the vulnerability.
+Use [GitHub Security Advisories](https://github.com/sheeki03/schrute/security/advisories/new) to submit a private report.
 
-2. **Email**: Send details to the repository maintainers via the email listed in the GitHub profile.
+### If Advisories Are Not Available
 
-### What to Include
+Contact the maintainers privately through the repository's listed contact channels. Do not open a public GitHub issue for an undisclosed vulnerability.
 
-- Description of the vulnerability
-- Steps to reproduce
-- Potential impact
-- Suggested fix (if any)
+### What To Include
 
-### What to Expect
+- A clear description of the issue
+- Affected version, commit, or deployment context
+- Reproduction steps or a proof of concept
+- Expected impact
+- Any suggested mitigation or patch idea
 
-- Acknowledgment within 48 hours
-- Status update within 7 days
-- We aim to release fixes within 30 days of confirmed vulnerabilities
+### Response Targets
+
+- Initial acknowledgment within 48 hours
+- A status update within 7 days
+- A fix or mitigation plan as soon as the issue is confirmed and triaged
 
 ## Scope
 
 ### In Scope
 
-- Authentication bypass in HTTP transport
-- SSRF via skill execution
-- Policy gate bypass
-- Credential leakage (auth tokens, cookies)
-- Command injection via skill parameters
-- Audit log tampering
-- Path traversal in data directory operations
+- Authentication or authorization bypass in network mode
+- Policy or confirmation gate bypass
+- SSRF or private-network access through discovery or replay
+- Credential leakage, token exposure, or cookie isolation failures
+- Command injection, path traversal, or unsafe local file access
+- Audit-log tampering or integrity bypass
 
 ### Out of Scope
 
-- Denial of service (Schrute is a local tool)
-- Issues requiring physical access
 - Social engineering
-- Issues in dependencies (report upstream)
+- Vulnerabilities that depend on physical access to the machine
+- Issues only affecting third-party dependencies without a Schrute-specific exploit path
+- Pure availability issues on a local-only deployment with no confidentiality or integrity impact
 
-## Security Architecture
+## Security Model At A Glance
 
-Schrute's security model is documented in `CLAUDE.md`. Key protections:
+Schrute is designed to fail closed. Important protections in the codebase include:
 
-- **9 policy gates** on every skill execution
-- **Fail-closed auth** for network mode (HTTP transport)
-- **HMAC-chained audit log** for tamper detection
-- **Timing-safe token comparison** to prevent timing attacks
-- **Domain allowlists** per site
-- **SSRF prevention** blocking private IP targets
-- **One-time confirmation** required for all new skills
-- **Credential isolation** — auth tokens never persist to config files
+- Policy checks around skill execution and browser-backed actions
+- Domain allowlists and request-shaping controls
+- SSRF protections, including private-IP blocking and redirect validation
+- Confirmation requirements for sensitive or newly learned actions
+- Audit logging and redaction for execution visibility
+- Timing-safe token verification for authenticated HTTP access
+- Separation of stored site data from runtime credentials where possible

README.md

@@ -107,8 +107,6 @@
     "NOTICE",
     "CONTRIBUTING.md",
     "SECURITY.md",
-    "CLAUDE.md",
-    "AGENTS.md",
     "scripts/sync-version.js"
   ]
 }