Revert "createos-fullstack-skills"

[Sid-NodeOps]

Reverts #5

[pratikbin]

roborev: Combined Review (5c7d9729)

Synthesis unavailable. Showing raw review outputs.

Agent: opencode | Type: security | Status: done

These commits add documentation/contract files only (no runtime code), so there is no direct exploitable injection/path traversal/etc introduced in the diff itself.
However, there are security-control gaps in the new contracts that can lead to insecure generated backends.

• Severity: Medium
  File: skills/createos-fs/SKILL.md (sections: “Clarification Questions”, “Output Requirements”) and skills/createos-fs/ARCHITECTURE_CONTRACT.md (API layer allows auth checks but does not require them)
  Issue: Authentication/authorization is not mandated as a baseline for generated APIs.
  Risk: Generated endpoints may be shipped without auth or with inconsistent authorization checks, creating broken access control / privilege escalation paths.
  Remediation: Add a mandatory security section requiring explicit authN/authZ decisions per endpoint (public vs protected), default-deny policy, and role/ownership checks in controllers/services.

• Severity: Low
  File: skills/createos-fs/SWAGGER_CONTRACT.md (mandatory docs endpoint exposure) and skills/createos-fs/SKILL.md (/docs default exposure)
  Issue: Swagger endpoint exposure is required but there is no requirement for environment gating or access control in production.
  Risk: Public API surface disclosure can aid reconnaissance and endpoint abuse.
  Remediation: Require one of: disable docs in production, protect docs with auth/IP allowlist, or serve only sanitized specs without internal/admin endpoints.

• Severity: Low
  File: skills/createos-fs/SKILL.md and contracts set (no dependency security requirements)
  Issue: No explicit requirement for dependency pinning/auditing for generated Node.js backends.
  Risk: Increased chance of vulnerable or typosquatted packages entering generated projects.
  Remediation: Add contract rules for lockfile enforcement, pinned versions/ranges policy, npm/bun audit (or equivalent) in CI, and trusted registry constraints.

If you want, I can provide a patch-ready “SECURITY_CONTRACT.md” that plugs these gaps and is consistent with the existing contract style.

Agent: opencode | Type: design | Status: done

The design introduces a contract-driven backend skill for Node.js/Express with separate contract docs for architecture, DB, migrations, config, Swagger, placeholders, README, code quality, and non-goals. The intent is good: constrain overengineering and enforce consistency while letting prompt scope features.

PRD Findings

• High — The docs are not reliably consumable due to multiple corrupted/truncated lines (examples: erns only, Ãrganized differently, explvalues, Error messast, Swaggerust, malformed markdown endings).
  Suggested improvement: fix all text corruption and run a docs lint/check before merge.
• High — Internal contradictions reduce trust in the spec: SKILL.md says “Only SKILL.md is required,” but also declares many mandatory contracts.
  Suggested improvement: define one authoritative structure and remove conflicting statements.
• High — Feasibility is weakly grounded in repository reality: path/name mismatch (skills/createos-fs/... vs skills/backend-api-nodejs/...) and no clear wiring for how contracts are enforced at runtime.
  Suggested improvement: align actual folder/name conventions and document contract enforcement mechanism.
• Medium — Success criteria are mostly qualitative (“easy to reason about”, “clean”), not testable.
  Suggested improvement: add measurable checks (e.g., “no direct DB imports in controllers,” “all routes present in OpenAPI,” “startup fails if required env vars missing”).
• Medium — Backward compatibility is underdefined: API versioning and migration rollout strategy are mentioned only partially.
  Suggested improvement: define explicit policy for breaking API/schema changes and compatibility windows.
• Medium — Security treatment is incomplete (secrets/logging covered, but authn/authz, input sanitization expectations, abuse controls, and PII handling are not).
  Suggested improvement: add minimum security baseline contract.

Task List Findings

• High — No implementation task list/staged rollout exists in these changes.
  Suggested improvement: add phased tasks (draft contracts → validate against sample backend → add automated checks → integrate skill loader → release).
• High — No dependency ordering for delivery (e.g., define contracts before SKILL wiring, then test harness, then docs).
  Suggested improvement: include ordered milestones with entry/exit criteria per phase.
• Medium — No incremental review checkpoints.
  Suggested improvement: split into small reviewable units (contracts text quality pass, consistency pass, enforcement pass, example project pass).
• Medium — No ownership/acceptance criteria per task.
  Suggested improvement: assign clear done criteria and verification commands.

Missing Considerations

• Automated compliance checks (linting/validation for contracts, OpenAPI drift checks, architecture boundary checks).
• Test strategy (unit/integration/e2e expectations for generated backends).
• Operational concerns (logging format, health checks, observability baseline).
• Error taxonomy/HTTP mapping standardization beyond “handle errors explicitly.”
• Change management for contract evolution (versioning of contracts themselves).

Verdict

• Fail — Strong intent and structure, but currently not passable as a design artifact due to document corruption, internal inconsistencies, lack of implementation/task plan, and insufficiently measurable acceptance criteria.