Merge order for the rebased PR queue (verified conflict-free for 13 of 15)

[adityamparikh]

All the open PRs authored by me are now rebased on main (a84033b) and individually green. But they are not independently mergeable — several touch the same files, so merging them in an arbitrary order stalls on conflicts roughly every second merge.

This issue records an order that has been empirically verified, not reasoned about: I replayed candidate orders as real merges onto a84033b and measured which conflicted.

The overlap that causes it

File	PRs competing for it
CollectionService.java	#103, #108, #110, #111
SchemaService.java	#98, #108, #110
SearchService.java	#108, #110, #164
IndexingService.java	#108, #110
build.gradle.kts	#104, #35, #136

#108 (collection-name validation) and #110 (SLF4J logging) are the hubs — between them they touch all four service classes.

Recommended order

Merging in this sequence, 13 of these merge with zero conflicts:

#	PR	Area
1	#175	JsonResponseParser — empty-facet fix
2	#99	SearchResponse
3	#104	solr.url validation
4	#105	document-creator blank input
5	#162	MCP server instructions
6	#174	release workflow fixes
7	#143	docs site (still blocked on the dev@ discussion — skip if unresolved; it conflicts with nothing)
8	#53	spec doc (draft)
9	#111	narrow metrics catch clauses
10	#103	CollectionService visibility
11	#164	typed SortClause
12	#108	unified collection-name validation
13	#136	cut 1.0.0 (per @epugh, this goes to branch_1_0_0, not main)

Verified: with those 13 merged together, ./gradlew build is green on JDK 25 — 415 tests, 0 failures, 7 skipped. So the sequence is not just conflict-free, it is semantically consistent.

The two that need a rebase, and why

• feat: add SLF4J logging to all service classes #110 (SLF4J logging) — conflicts on CollectionService + SearchService whatever the order. It adds logging inside the same catch blocks fix: validate collection name consistently across all MCP tool methods #108 and fix: narrow catch clauses in fetchCacheMetrics/fetchHandlerMetrics #111 modify, so it is inherently last-mover. I'll rebase it once fix: validate collection name consistently across all MCP tool methods #108 lands.
• fix: narrow SchemaService.getSchema() throws clause #98 (getSchema throws clause) — conflicts with fix: validate collection name consistently across all MCP tool methods #108 on SchemaService. Six lines; trivial rebase. One of fix: narrow SchemaService.getSchema() throws clause #98/fix: validate collection name consistently across all MCP tool methods #108 must move, and fix: validate collection name consistently across all MCP tool methods #108 is the larger change, so fix: narrow SchemaService.getSchema() throws clause #98 is the cheaper one to rebase.

Ordering alternatives I measured, for the record:

Order	Clean	Needed rebase
Recommended (above)	13	#110, #98
Isolated first, hubs last	13	#108, #110
Hubs (#108, #110) first	12	#98, #111, #164
#110 before the singles	12	#111, #164, #98

Two rebases appears to be the floor — #110 and one of #98/#108 conflict pairwise no matter what.

Separately: #35 vs #136

These collide by design and it is not an ordering problem. Both rewrite the same line in build.gradle.kts: #136 pins version = "1.0.0", #35 replaces it with version = semver.version (git-semver-plugin). Manual pin vs. automatic derivation — whichever lands second needs a deliberate re-resolve, not a mechanical rebase. Per the discussion on #35, the plan is 1.0.0 first, tag it as the semver baseline, then #35. #35 is in any case parked behind getting one real release out.

Not in this list

• feat: Spring Boot 4 + Spring AI 2.0 upgrade #23 (Spring Boot 4 / Spring AI 2.0) — parked behind the 1.0 release; rebased and green (372 tests) but deliberately out of the queue.
• Adding MCP endpoint for finding ref guide URLs #86, feat(indexing): add markdown document indexing #144, feat(collection): added alias management #159 — other contributors'. feat(indexing): add markdown document indexing #144 and feat(collection): added alias management #159 are waiting on merge PRs I opened against their forks (shahzadarain/solr-mcpErrorprone spotless #3, y-luis-rojo/solr-mcp[SOLR-17944] PR feedback - add spotless. #2).

Happy to do the #110 and #98 rebases as soon as their predecessors land — just ping me, or they can be done in a batch at the end.