# Rudis Optional Integration

Rudis integration lets SPARK consume Rudis planning artifacts as optional external knowledge. It is opt-in, read-only, and does not make Rudis a dependency of SPARK.

## Enable

From the project root:

```bash
spark integration install rudis
```

This writes:

```text
.spark/integrations/rudis.json
```

Default marker:

```json
{
  "enabled": true,
  "mode": "read-only",
  "constitution": ".rudis/memory/constitution.md",
  "specs": "specs",
  "adapter": ".agents/skills/rudis-adapter"
}
```

The command also installs the adapter skill into `.agents/skills/rudis-adapter` for the current project. It does not install Rudis, run Rudis, or modify `.rudis/`.

## Consumed Artifacts

When enabled, use the `rudis-adapter` skill to read existing artifacts:

```text
.rudis/memory/constitution.md
specs/<feature>/spec.md
specs/<feature>/plan.md
specs/<feature>/tasks.md
specs/<feature>/research.md
specs/<feature>/data-model.md
specs/<feature>/quickstart.md
```

Missing artifacts are reported as gaps. They are not generated by SPARK.

## Flow

Existing project with SPARK only:

```text
project-scanner
-> .docs baseline
-> knowledge-rules if enforcement is desired
-> template-generator
-> project-onboarding
```

Existing project with SPARK plus Rudis:

```text
spark integration install rudis
-> rudis-adapter loads External Knowledge Adapter Context
-> project-scanner uses codebase plus adapter evidence
-> .docs remains the SPARK memory baseline
-> knowledge-rules proposes approved rules from stable evidence
-> template-generator and project-onboarding consume SPARK contracts as usual
```

Rudis task continuation with SPARK:

```text
spark integration install rudis
-> rudis-adapter reads specs/<feature>/tasks.md
-> rudis-adapter emits Rudis Task Intake
-> writing-plans expands Rudis task intent into a SPARK implementation plan
-> subagent-driven-development or executing-plans performs TDD, review, and verification
```

In this flow, Rudis owns the feature intent and high-level task order. SPARK owns detailed implementation planning and execution discipline. Keep Rudis task IDs in the SPARK plan so work can be traced back to the original `tasks.md`.

Example request:

```text
Continue my Rudis tasks with SPARK.
```

If the project has multiple feature folders, name the one you want:

```text
Continue my Rudis tasks for specs/001-invoice with SPARK.
```

New generated project:

```text
project-onboarding
-> project-scanner after generation
-> optional rudis-adapter only if the new project also enables Rudis integration
```

## Boundaries

- SPARK core skills stay Rudis-neutral.
- Rudis artifacts are read-only external evidence.
- `.docs/` is still generated only by `project-scanner`.
- `KNOWLEDGE_RULES.md` still requires developer approval for every rule.
- `template-generator` and `project-onboarding` still depend on SPARK `.docs/`, approved rules, and `.template/` contracts.
- Rudis task lists are implementation guidance, not stable architecture memory.
- Rudis `tasks.md` is not executed directly by SPARK; it is normalized into Rudis Task Intake and expanded by `writing-plans`.