Skip to content

Spikes

# Title Lead Mode Status
Spike 1 KMaps field type on Drupal 11 Yuji ● Proven
Spike 2 Solr index read-only integration Yuji Team candidate ● Proven
Spike 3 Group module collections architecture Than Team candidate ◐ Partial
Spike 4 CKEditor 5 footnotes + Tibetan Unicode Than Individual ○ Pending
Spike 5 bibcite for Sources site Xiaoming Individual ○ Pending
Spike 6 API compatibility for React application Than Team candidate ○ Pending
Spike 7 Kaltura AV integration on Drupal 11 Individual ○ Pending
Spike 8 reindeer_x consolidation as managed sync subsystem Yuji Individual ◐ Partial
Spike 9 Documentation hosting & access control (mkdocs → public + Confluence) Yuji Individual ○ Pending (low priority)
Spike 10 SAML + OAuth2 coexistence on D11 (simplesamlphp_auth + simple_oauth) Yuji Individual ● Proven — 1b.1 unblocked (2026-07-09)

Status key: ● Proven · ◐ Partial / in progress · ○ Pending

See docs/planning/spikes-plan.md for full spike definitions and pass/fail criteria.


Each file records the outcome of a time-boxed technical spike. The purpose is to document what was proven (or disproven), what the demo shows, and what the spike explicitly does not establish — so downstream decisions are made on accurate evidence.

Template

# Spike N: Title
**Status:** Proven / Not proven / Partial
**Date:** YYYY-MM
**Branch/commit:** (link or SHA)

## Theory
One sentence: what we were trying to prove.

## Demo
How to see the result. URLs, drush commands, screenshots if needed.

## Findings
What was demonstrated. Be precise about scope.

## What this does NOT establish
Explicit statement of boundaries — what future work still needs to prove.

## Deferred notes
Links to docs/deferred/ items generated during this spike.