feature/resource-deltas-founding-date-multi-chain #18

Merged

Xeplosion merged 4 commits from dev into main 2026-08-27 20:23:21 +00:00

Conversation 0 Commits 4 Files changed 3 +184 -27

Xeplosion commented 2026-08-27 20:23:15 +00:00

Owner

Copy link

What changed and why

Implements three related capture-model improvements, discussed and confirmed
before building:

Resource quantification for add-ons (issue #3). Add-ons that grant more
of a resource tracked elsewhere (RAM, storage, backup capacity, instance
slots) could previously only describe that in free-text notes, making an
offering's effective total (base + purchased add-ons) uncomputable
downstream. Added addon.resource_deltas — a closed-vocabulary map of
resource → increase amount — plus instance_slots as a new config
vocabulary entry (needed regardless of add-ons, since multi-instance-panel
providers like BisectHosting had no field for baseline instance count at
all). Non-quantitative grants (Discord perks, vanity subdomains) still stay
in notes.

Optional founding date / earliest review date (issue #4). Added
provider.founding_date and provider.reviews.earliest_review_date, both
nullable ISO dates. Two separate raw fields rather than one merged
"estimate" object, consistent with how the rest of the schema keeps raw
facts separate (e.g. complies_with_guidelines / compliance_notes).
earliest_review_date serves as a lower-bound proxy when founding date is
unstated/undiscoverable.

Multiple main/flagship offerings per line (issue #5). is_main_offering
was never schema-constrained — the "at most one true per line" limit was
purely a misleading schema description string plus the capture-form's own
client-side check. Removed the check, corrected the description, since
providers sometimes genuinely co-emphasize multiple offerings equally.

All three schema additions are optional/nullable and not in any required
array, so every existing provider file remains valid unmodified — no
migration needed.

Related issues

Closes #3
Closes #4
Closes #5

How to test

1. pytest — 71 tests, all should pass unmodified against the updated
   schema (purely additive changes).
2. Open the capture-form, open any provider, go to an offering's
   Configuration section — confirm an "Instance slots" field appears.
3. Mark two offerings on the same product line as "main / flagship
   offering" — confirm no validation error is raised (previously blocked
   at "more than one offering marked main").
4. On an add-on, check "This add-on increases capacity of an existing
   resource" — confirm a grid of 8 resource fields appears, and that
   filling in only some of them (e.g. just instance_slots and
   storage_gb) omits the rest from the saved JSON rather than writing
   them as zero.
5. On the Provider step, fill in "Founding date"; on the Reviews step,
   fill in "Earliest review date" — save, reopen the file, confirm both
   values persisted.
6. Validate a saved file with capture-validate (or against
   schema/provider-schema-v2.3.json directly) and confirm it passes.

Checklist

• Tests added or updated
• Docs updated if behaviour changed
• No unrelated changes included
• PR is focused on one thing

Release notes

Add optional founding-date and earliest-review-date fields, structured resource_deltas for add-ons, an instance_slots config field, and allow multiple offerings to be marked main/flagship per product line.

## What changed and why Implements three related capture-model improvements, discussed and confirmed before building: **Resource quantification for add-ons (issue #3).** Add-ons that grant more of a resource tracked elsewhere (RAM, storage, backup capacity, instance slots) could previously only describe that in free-text `notes`, making an offering's effective total (base + purchased add-ons) uncomputable downstream. Added `addon.resource_deltas` — a closed-vocabulary map of resource → increase amount — plus `instance_slots` as a new `config` vocabulary entry (needed regardless of add-ons, since multi-instance-panel providers like BisectHosting had no field for baseline instance count at all). Non-quantitative grants (Discord perks, vanity subdomains) still stay in `notes`. **Optional founding date / earliest review date (issue #4).** Added `provider.founding_date` and `provider.reviews.earliest_review_date`, both nullable ISO dates. Two separate raw fields rather than one merged "estimate" object, consistent with how the rest of the schema keeps raw facts separate (e.g. `complies_with_guidelines` / `compliance_notes`). `earliest_review_date` serves as a lower-bound proxy when founding date is unstated/undiscoverable. **Multiple main/flagship offerings per line (issue #5).** `is_main_offering` was never schema-constrained — the "at most one true per line" limit was purely a misleading schema description string plus the capture-form's own client-side check. Removed the check, corrected the description, since providers sometimes genuinely co-emphasize multiple offerings equally. All three schema additions are optional/nullable and not in any `required` array, so every existing provider file remains valid unmodified — no migration needed. ## Related issues Closes #3 Closes #4 Closes #5 ## How to test 1. `pytest` — 71 tests, all should pass unmodified against the updated schema (purely additive changes). 2. Open the capture-form, open any provider, go to an offering's Configuration section — confirm an "Instance slots" field appears. 3. Mark two offerings on the same product line as "main / flagship offering" — confirm no validation error is raised (previously blocked at "more than one offering marked main"). 4. On an add-on, check "This add-on increases capacity of an existing resource" — confirm a grid of 8 resource fields appears, and that filling in only some of them (e.g. just `instance_slots` and `storage_gb`) omits the rest from the saved JSON rather than writing them as zero. 5. On the Provider step, fill in "Founding date"; on the Reviews step, fill in "Earliest review date" — save, reopen the file, confirm both values persisted. 6. Validate a saved file with `capture-validate` (or against `schema/provider-schema-v2.3.json` directly) and confirm it passes. ## Checklist - [x] Tests added or updated - [x] Docs updated if behaviour changed - [ ] No unrelated changes included - [x] PR is focused on one thing ## Release notes Add optional founding-date and earliest-review-date fields, structured resource_deltas for add-ons, an instance_slots config field, and allow multiple offerings to be marked main/flagship per product line.

Xeplosion added 4 commits 2026-08-27 20:23:15 +00:00

feat(schema): add instance_slots, addon.resource_deltas, found_date, and earliest_review_date; allow multiple main offerings. e951a4155f

feat(capture-form): UI for instance_slots, resource_deltas, founding_date, earliest_review_date; remove one-main-offering-per-line limit. 7e2271ce57

docs: document resource_deltas, instance_slots, founding_date, earliest_review_date, and the relaxed main-offering rule. 4334405e6d

Merge pull request 'feature/resource-deltas-founding-date-multi-chain' (#17) from feature/resource-deltas-founding-date-multi-chain into dev ... b5b3ff71aa

Reviewed-on: #17

Xeplosion merged commit 15355f077c into main 2026-08-27 20:23:21 +00:00

Xeplosion referenced this pull request from a commit 2026-08-27 20:23:22 +00:00

Merge pull request 'feature/resource-deltas-founding-date-multi-chain' (#18) from dev into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

  

Compat/Breaking

Introduces a breaking change — not backward compatible

  

Compat/Deprecation

Deprecates something that will be removed in a future release

  

Kind

Bug

Something is not working

  

Kind

Chore

Maintenance, dependencies, tooling, tech debt

  

Kind

Documentation

Documentation changes

  

Kind

Enhancement

Improve existing functionality

  

Kind

Feature

New functionality

  

Kind

Investigation

Research or spike — output is findings, not necessarily a PR

  

Kind

Question

Question or discussion — no code change intended

  

Kind

Security

Security-related issue or fix

  

Kind

Testing

Related to tests or test infrastructure

  

Meta/Good First Issue

Good entry point for new contributors

  

Meta/Help Wanted

Extra attention or outside help welcome

  

Meta/Stale

No activity for 60+ days — will be closed if no response

  

Priority

Critical

Drop everything — production is broken or data is at risk

  

Priority

High

Next up — significant impact, should ship soon

  

Priority

Low

Nice to have — pick up when bandwidth allows

  

Priority

Medium

Important but not blocking anything

  

Reviewed

Confirmed

Issue is valid and ready to be worked on

  

Reviewed

Duplicate

Already tracked in another issue

  

Reviewed

Invalid

Cannot reproduce, out of scope, or not a real issue

  

Reviewed

Won't Fix

Acknowledged but will not be addressed

  

Status

Abandoned

Work was started but the contributor stepped away

  

Status

Blocked

Cannot proceed — waiting on something external

  

Status

Need More Info

Waiting on additional information from the reporter

  

Status/Needs Triage

Newly opened — awaiting review, kind, and priority assignment

No labels

Compat/Breaking

Compat/Deprecation

Kind

Bug

Kind

Chore

Kind

Documentation

Kind

Enhancement

Kind

Feature

Kind

Investigation

Kind

Question

Kind

Security

Kind

Testing

Meta/Good First Issue

Meta/Help Wanted

Meta/Stale

Priority

Critical

Priority

High

Priority

Low

Priority

Medium

Reviewed

Confirmed

Reviewed

Duplicate

Reviewed

Invalid

Reviewed

Won't Fix

Status

Abandoned

Status

Blocked

Status

Need More Info

Status/Needs Triage

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

XeplosionGames/minecraft-provider-analysis!18

No description provided.