From fbcb4113f110a7db9cf21d18510cb59c2e90ba23 Mon Sep 17 00:00:00 2001 From: Christian Cleberg Date: Sun, 2 Aug 2026 15:29:33 -0500 Subject: convert readme to nfo; convert docs to txt; relicense to 0bsd --- Docs/API_CACHE.md | 11 ----------- Docs/API_CACHE.txt | 11 +++++++++++ Docs/StoreKit.md | 42 ------------------------------------------ Docs/StoreKit.txt | 42 ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 53 insertions(+), 53 deletions(-) delete mode 100644 Docs/API_CACHE.md create mode 100644 Docs/API_CACHE.txt delete mode 100644 Docs/StoreKit.md create mode 100644 Docs/StoreKit.txt (limited to 'Docs') diff --git a/Docs/API_CACHE.md b/Docs/API_CACHE.md deleted file mode 100644 index 456beb2..0000000 --- a/Docs/API_CACHE.md +++ /dev/null @@ -1,11 +0,0 @@ -# SourceHut API Cache - -Hutch caches read-only SourceHut API responses at the `SRHTClient` boundary. The cache stores raw response bytes plus metadata on disk, with a small bounded memory layer for hot entries. Disk files are account-scoped under the app caches directory, and `PersistentAPICache` is an actor so disk I/O, pruning, and metadata updates stay off the main actor. - -Cache keys are built in `APICacheKeys`. Keys are explicit and include the service plus request-shaping inputs such as repository IDs, refs, tree/blob IDs, paths, owners, ticket IDs, job IDs, log URLs, cursors, and filters. Views and view models should not invent ad hoc cache strings. - -TTLs live in `APICacheTTLs`. Active build data uses a very short TTL, mutable ticket and list data use medium-short TTLs, repository metadata and profile data live longer, completed build logs are long-lived, and content-addressed git objects are treated as mostly immutable. Moving refs such as `HEAD` use shorter file/content TTLs. - -Invalidation is intentionally prefix-based. Successful ticket mutations remove ticket, ticket-list, tracker, and Home prefixes. Build retry/cancel/resubmit actions remove build detail, build-list, build-log, and Home prefixes. This avoids a dependency graph while keeping stale post-mutation data out of the high-risk paths. - -Known limitations: caching now covers the high-value detail paths plus repository/build/ticket/tracker/paste lists, profile repositories/trackers, projects, and Home dashboard fetches. Some services still perform background refresh one request at a time rather than streaming partial refreshed list pages into the UI, and Work Queue-specific surfaces should be reviewed as a follow-up if they grow beyond the Home dashboard data model. diff --git a/Docs/API_CACHE.txt b/Docs/API_CACHE.txt new file mode 100644 index 0000000..456beb2 --- /dev/null +++ b/Docs/API_CACHE.txt @@ -0,0 +1,11 @@ +# SourceHut API Cache + +Hutch caches read-only SourceHut API responses at the `SRHTClient` boundary. The cache stores raw response bytes plus metadata on disk, with a small bounded memory layer for hot entries. Disk files are account-scoped under the app caches directory, and `PersistentAPICache` is an actor so disk I/O, pruning, and metadata updates stay off the main actor. + +Cache keys are built in `APICacheKeys`. Keys are explicit and include the service plus request-shaping inputs such as repository IDs, refs, tree/blob IDs, paths, owners, ticket IDs, job IDs, log URLs, cursors, and filters. Views and view models should not invent ad hoc cache strings. + +TTLs live in `APICacheTTLs`. Active build data uses a very short TTL, mutable ticket and list data use medium-short TTLs, repository metadata and profile data live longer, completed build logs are long-lived, and content-addressed git objects are treated as mostly immutable. Moving refs such as `HEAD` use shorter file/content TTLs. + +Invalidation is intentionally prefix-based. Successful ticket mutations remove ticket, ticket-list, tracker, and Home prefixes. Build retry/cancel/resubmit actions remove build detail, build-list, build-log, and Home prefixes. This avoids a dependency graph while keeping stale post-mutation data out of the high-risk paths. + +Known limitations: caching now covers the high-value detail paths plus repository/build/ticket/tracker/paste lists, profile repositories/trackers, projects, and Home dashboard fetches. Some services still perform background refresh one request at a time rather than streaming partial refreshed list pages into the UI, and Work Queue-specific surfaces should be reviewed as a follow-up if they grow beyond the Home dashboard data model. diff --git a/Docs/StoreKit.md b/Docs/StoreKit.md deleted file mode 100644 index 0d2eb33..0000000 --- a/Docs/StoreKit.md +++ /dev/null @@ -1,42 +0,0 @@ -# StoreKit Setup For Hutch - -Hutch uses StoreKit 2 for one-time consumable tip products: - -- `net.cleberg.hutch.tip.small` -- `net.cleberg.hutch.tip.medium` -- `net.cleberg.hutch.tip.large` - -## Xcode setup - -1. Open `Hutch.xcodeproj` in Xcode. -2. Select the `Hutch` target. -3. Open `Signing & Capabilities`. -4. Confirm the App ID for `net.cleberg.Hutch` has the In-App Purchase capability enabled in the Apple Developer portal. -5. In Xcode, choose `File > New > File... > StoreKit Configuration File`. -6. Prefer a synced StoreKit file so Xcode pulls the real products from App Store Connect. -7. Open `Product > Scheme > Edit Scheme...`. -8. Select `Run`, then the `Options` tab. -9. Set `StoreKit Configuration` to the synced `.storekit` file for local testing. - -## App Store Connect checks - -1. Confirm all three products exist with the exact product IDs listed above. -2. Confirm each product has complete metadata, pricing, and availability. -3. If a product is in `Developer Action Needed`, edit the rejected detail or cancel the pending change, then resubmit it. -4. Wait up to one hour for metadata changes to propagate to sandbox. - -## Sandbox test checklist - -1. On a physical device, enable Developer Mode if needed. -2. Sign in to a Sandbox Apple Account in `Settings > Developer > Sandbox Apple Account`. -3. Install a development build from Xcode or a TestFlight build. -4. Open `More > About`. -5. Verify the tip products load with names and prices. -6. Complete one purchase successfully. -7. Use `Restore / Sync Purchases` to verify StoreKit can talk to the App Store account. -8. Record this full flow for App Review when resubmitting. - -## Code locations - -- `Hutch/Views/More/TipStoreViewModel.swift` -- `Hutch/Views/More/AboutView.swift` diff --git a/Docs/StoreKit.txt b/Docs/StoreKit.txt new file mode 100644 index 0000000..0d2eb33 --- /dev/null +++ b/Docs/StoreKit.txt @@ -0,0 +1,42 @@ +# StoreKit Setup For Hutch + +Hutch uses StoreKit 2 for one-time consumable tip products: + +- `net.cleberg.hutch.tip.small` +- `net.cleberg.hutch.tip.medium` +- `net.cleberg.hutch.tip.large` + +## Xcode setup + +1. Open `Hutch.xcodeproj` in Xcode. +2. Select the `Hutch` target. +3. Open `Signing & Capabilities`. +4. Confirm the App ID for `net.cleberg.Hutch` has the In-App Purchase capability enabled in the Apple Developer portal. +5. In Xcode, choose `File > New > File... > StoreKit Configuration File`. +6. Prefer a synced StoreKit file so Xcode pulls the real products from App Store Connect. +7. Open `Product > Scheme > Edit Scheme...`. +8. Select `Run`, then the `Options` tab. +9. Set `StoreKit Configuration` to the synced `.storekit` file for local testing. + +## App Store Connect checks + +1. Confirm all three products exist with the exact product IDs listed above. +2. Confirm each product has complete metadata, pricing, and availability. +3. If a product is in `Developer Action Needed`, edit the rejected detail or cancel the pending change, then resubmit it. +4. Wait up to one hour for metadata changes to propagate to sandbox. + +## Sandbox test checklist + +1. On a physical device, enable Developer Mode if needed. +2. Sign in to a Sandbox Apple Account in `Settings > Developer > Sandbox Apple Account`. +3. Install a development build from Xcode or a TestFlight build. +4. Open `More > About`. +5. Verify the tip products load with names and prices. +6. Complete one purchase successfully. +7. Use `Restore / Sync Purchases` to verify StoreKit can talk to the App Store account. +8. Record this full flow for App Review when resubmitting. + +## Code locations + +- `Hutch/Views/More/TipStoreViewModel.swift` +- `Hutch/Views/More/AboutView.swift` -- cgit v1.2.3