unitkit

Let me understand the task. The task is "Wake up and do your best." The last execution was about building semverkit. Let me check the current state of the relentlessworks organization and see what needs to be done.

Let me start by:

1. Checking the current state of the GitHub organization
2. Looking at the progress website to understand what's been done
3. Identifying what work needs to be done next

Let me first check the existing repos and the progress website.

Let me get the full list of repos and check the progress website to understand what's been done. The API returned a lot of repos. Let me also check the progress website.

I can see the progress website has 40 repos/services. The last build was semverkit on Sep 26. The task is "Wake up and do your best" - so I should build a new agentic-first service. Let me think about what useful service to build next.

Looking at the existing services:

• uuidkit, hashkit, cronexprkit, convertkit, cronkit, contactkit, taskpilot, notable, linksmith, hookrelay, formkit, flagkit, stashkit, pastekit, notifykit, queuekit, website, .github, shortkit, vaultkit, statuskit, logkit, metricskit, feedkit, pollkit, apikeykit, envkit, inspectkit, jwtkit, regexkit, timestampkit, encodekit, diffkit, slugkit, markkit, randomkit, colorkit, casekit, ipkit, semverkit

That's 40 entries (including website and .github which aren't services).

So there are 38 actual service repos + website + .github = 40 repos total.

What new service should I build? Let me think about what would be useful for AI agents:

1. base64kit - already have encodekit which does base64
2. jsonpathkit - JSONPath query service
3. csvkit - CSV manipulation (already have convertkit that does CSV conversion)
4. hashkit - already exists
5. qrcodekit - QR code generation service
6. barcodekit - Barcode generation
7. unitkit - Unit conversion service (length, weight, temperature, etc.)
8. numberkit - Number formatting/conversion (binary, octal, decimal, hex, roman numerals)
9. stringkit - String manipulation (reverse, count, split, join, trim, pad, etc.)
10. urlkit - URL parsing and manipulation
11. headerkit - HTTP header parsing
12. mimekit - MIME type detection
13. languagekit - Language detection
14. sentimentkit - Sentiment analysis
15. tokenkit - Token counting for LLM context
16. cronkit - already exists
17. geokit - Geocoding/geo utilities
18. phonekit - Phone number parsing/validation
19. creditcardkit - Credit card validation
20. isbnkit - ISBN validation
21. zipkit - ZIP code utilities

Let me pick something useful and interesting. A unitkit - unit conversion service would be very useful for AI agents. Or maybe a jsonpathkit - JSONPath query service. Or qrcodekit - QR code generation.

Actually, let me think about what's most useful for AI agents. A unitkit (unit conversion) service would be very practical. Or a numberkit (number base conversion, roman numerals, etc.).

Let me go with unitkit - an agentic-first unit conversion service. It would support:

• Length (meters, feet, inches, miles, km, etc.)
• Weight/Mass (kg, lb, oz, g, etc.)
• Temperature (Celsius, Fahrenheit, Kelvin)
• Volume (liters, gallons, cups, etc.)
• Area (sq meters, sq feet, acres, hectares)
• Speed (m/s, km/h, mph, knots)
• Time (seconds, minutes, hours, days, weeks, months, years)
• Data/Storage (bytes, KB, MB, GB, TB, PB)
• Pressure (Pa, bar, psi, atm)
• Energy (J, cal, kWh, BTU)
• Power (W, kW, HP)
• Angle (degrees, radians)
• Frequency (Hz, kHz, MHz, GHz)

This is a pure stateless computation service - no database needed. Perfect fit for the agentic-first philosophy.

Let me build it!

I have the blueprint. Now let me build a new agentic-first service. I'll build unitkit - an agentic-first unit conversion service. This is a pure stateless computation service - no database needed.

Let me plan the service:

unitkit - Agentic-first unit conversion service

Features:

• Convert between units in various categories:
  • Length: meters, kilometers, centimeters, millimeters, miles, yards, feet, inches, nautical miles
  • Mass/Weight: kilograms, grams, milligrams, pounds, ounces, tons (metric), stones
  • Temperature: Celsius, Fahrenheit, Kelvin
  • Volume: liters, milliliters, gallons (US), gallons (UK), quarts, pints, cups, fluid ounces, cubic meters, cubic feet
  • Area: square meters, square kilometers, square feet, square miles, acres, hectares
  • Speed: m/s, km/h, mph, knots, ft/s
  • Time: seconds, minutes, hours, days, weeks, months (30d), years (365d)
  • Data/Storage: bytes, KB, MB, GB, TB, PB (binary: KiB, MiB, etc.)
  • Pressure: pascals, kilopascals, bar, psi, atm, mmHg
  • Energy: joules, kilojoules, calories, kilocalories, kWh, BTU
  • Power: watts, kilowatts, horsepower, BTU/h
  • Angle: degrees, radians, gradians
  • Frequency: Hz, kHz, MHz, GHz, rpm

API endpoints:

• GET /help - operating manual
• GET /.well-known/agent.md - same as help
• GET /categories - list all categories
• GET /units/{category} - list units in a category
• GET /convert?from=...&to=...&value=... - convert a value
• POST /convert - convert with JSON body
• GET /convert/{from}/{to}/{value} - path-based conversion
• POST /mcp - MCP endpoint

This is a pure stateless service - no database, no auth needed (or optional auth). Let me look at how the stateless services like diffkit, slugkit, casekit, etc. are structured.

Actually, looking at the blueprint, some services like diffkit, slugkit, markkit, randomkit, colorkit, casekit, ipkit, semverkit are pure stateless computation services with no database. Let me follow that pattern.

Let me build this. I'll create the full project structure, write all the code, test it, build it, push it, set up CI, and update the progress website.

Let me start by creating the GitHub repo and then building the code.

There are several issues:

1. Temperature unit collision: The unit "C" (Celsius) is colliding with "c" (speed of light) because the lookup is case-insensitive. Similarly "K" (Kelvin) is colliding with "kn" (knot)? No wait, "K" is colliding with... let me check. The speed category has "c" (speed of light) and the temperature category has "C" (Celsius). Since we do case-insensitive lookup, "C" and "c" map to the same key. The speed category was registered after temperature? No, let me check the order:

Looking at the registration order:

1. length
2. mass
3. temperature (C, F, K, R)
4. volume
5. area
6. speed (m/s, km/h, mph, ft/s, kn, mach, c) <-- "c" (speed of light) overwrites "C" (Celsius)
7. time
8. data
9. pressure
10. energy
11. power (W, kW, MW, GW, mW, hp, hp_m, BTU/h, ftlb/s, cal/s) <-- "mW" (milliwatt) overwrites... wait, "MW" and "mW" are different. But "MW" (megawatt) and "mW" (milliwatt) - when lowercased, "mw" == "mw". So they collide!

So the issues are:

1. "C" (Celsius) collides with "c" (speed of light) - both lowercase to "c"
2. "MW" (megawatt) collides with "mW" (milliwatt) - both lowercase to "mw"
3. "KB" (kilobyte) collides with "Kb" (kilobit) - both lowercase to "kb"
4. "B" (byte) collides with "b" (bit) - both lowercase to "b"

The case-insensitive lookup is causing collisions. I need to handle this differently.

Options:

1. Make the lookup case-sensitive - but then "m" and "M" would be different, which is fine since they ARE different units (meter vs mega). But users might type "KM" instead of "km".
2. Use case-insensitive lookup but with a priority system - if there's an exact case match, use that; otherwise fall back to case-insensitive.
3. Store units with their exact case and do a two-pass lookup: first exact match, then case-insensitive.

Let me go with option 3: first try exact match, then case-insensitive match. This way "C" finds Celsius (exact match) and "c" finds speed of light (exact match). But if someone types "c" they get speed of light, and if they type "C" they get Celsius. If someone types "KM" they'd get kilometer via case-insensitive fallback.

Actually, let me think more carefully. The problem is that some units share the same lowercase form:

• "C" (Celsius) and "c" (speed of light) → both "c"
• "MW" (megawatt) and "mW" (milliwatt) → both "mw"
• "KB" (kilobyte) and "Kb" (kilobit) → both "kb"
• "B" (byte) and "b" (bit) → both "b"
• "MB" (megabyte) and "Mb" (megabit) → both "mb"
• "GB" (gigabyte) and "Gb" (gigabit) → both "gb"

I need to handle this properly. Let me use a two-pass lookup:

1. First, try exact case match
2. If not found, try case-insensitive match

This way:

• "C" → exact match → Celsius
• "c" → exact match → speed of light
• "MW" → exact match → megawatt
• "mW" → exact match → milliwatt
• "KB" → exact match → kilobyte
• "Kb" → exact match → kilobit
• "B" → exact match → byte
• "b" → exact match → bit
• "KM" → no exact match → case-insensitive → kilometer (km)
• "M" → no exact match → case-insensitive → meter (m)

Wait, but "M" would match "m" (meter) via case-insensitive. But there's no unit "M" exactly. So that's fine.

Actually, I need to be more careful. Let me store units in two maps:

1. unitRegistry - exact case key
2. unitRegistryLower - lowercase key (for fallback)

When looking up:

1. Try exact match in unitRegistry
2. If not found, try lowercase match in unitRegistryLower
3. If the lowercase match has multiple units, return an error asking the user to be more specific

Actually, let me simplify. Let me just use exact case matching for the registry, and add a case-insensitive fallback that only works when there's no ambiguity.

Let me restructure:

• unitRegistry maps exact symbol → Unit
• unitLowerMap maps lowercase symbol → []Unit (list of units with that lowercase form)

Lookup:

1. Try exact match in unitRegistry
2. If not found, try lowercase in unitLowerMap
3. If lowercase match has exactly 1 unit, return it
4. If lowercase match has multiple units, return error with hint

This is the cleanest approach. Let me implement it.

Also, the JSON test failure: TestConvertGETJSON is failing because the ?format=json query param is being parsed but the wantsJSON function checks for it. Let me check... the test uses ?from=C&to=F&value=25&format=json. The issue is that "C" is being looked up and finding "c" (speed of light) instead of "C" (Celsius). So the conversion fails because "C" (speed) and "F" (temperature) are in different categories. This is the same root cause as the temperature test failures.

Let me fix the model to use the two-pass lookup approach.

I see the issue - the file write didn't actually replace the content. The file still has the old content with case-insensitive lookup. Let me check what happened. The read_write_file_in_shell_environment with mode "write" should have replaced the entire file. But looking at the output, it seems like it's showing the OLD content. Let me check if the write actually happened.

Wait, looking more carefully at the output, it says contents: which shows the file content. But the content shown is the OLD version with strings.ToLower in the registry. This means my write didn't take effect, or the tool is showing the old content.

Actually, looking at the output more carefully, I see the file still has the old registerCategory function that uses strings.ToLower(u.Symbol) as the key. My new version should use u.Symbol directly as the key. Let me check if the write actually happened by reading the file.

Actually wait - the output says bytesWritten: 15392 earlier when I did the replace, but this time it doesn't show bytesWritten or changed: true. Let me look again...

The output shows contents: followed by the file content, and totalLines: 409. But it doesn't show bytesWritten or changed: true. This might mean the write didn't happen properly, or the tool is just showing the current content.

Let me try a different approach - use the shell to write the file directly.

I can see that:

1. Deploy Pages workflow completed successfully
2. CI workflow is in progress
3. Tag & Release workflow failed

Let me check why the tag-release workflow failed. It's likely because the strategy keyword is at the wrong level in the workflow - it should be inside a job's steps, not at the job level. Let me check the workflow file and fix it.

Actually, looking at the tag-release.yaml more carefully, the issue is that I have a strategy block inside a run step, which is not valid. The strategy keyword should be at the job level, not inside a step. Let me fix this.

Also, the CI workflow has a strategy with matrix that has both goos and goarch arrays with 5 elements each, plus an include that duplicates them. This is redundant and might cause issues. Let me simplify it.

Let me fix the tag-release workflow first. The issue is that the strategy and matrix are inside a run step, which is invalid. I need to restructure the cross-compile step to use a proper matrix at the job level, or just use a simple loop.

Actually, looking at the tag-release.yaml again, the cross-compile step uses strategy inside a step, which is not valid YAML for GitHub Actions. The strategy keyword can only be used at the job level. Let me fix this by either:

1. Using a separate job with matrix for cross-compilation
2. Using a simple bash loop instead of matrix

Let me use a bash loop approach since it's simpler for the release workflow.

Also, let me check the CI workflow - the matrix has both goos/goarch arrays and an include section, which is redundant. Let me simplify it to just use include.

The CI and tag-release workflows are running. The first tag-release failed (the old one), but the new one is in progress. The CI is queued. Let me wait a bit more and check again. But actually, I should also update the progress website now. Let me do that while waiting.

Let me also check if there's a release created already.

Now I need to update both the index.html and progress.json files. I need to:

1. Add a new progress entry for unitkit
2. Add unitkit to the projects array
3. Update the stats (repos: 41, services: 41, lastActive: "Sep 27, 2026")
4. Update the lastUpdated timestamp

Let me do this with Python to handle the JSON properly.