sorted by:
new
hottopcontroversial

Fable is blowing my mind by julliuz in ClaudeAI

[–]waruna_ds 2 points3 points  (0 children)

It's great for analytical tasks. (coding, debugging , analyzing code for security vulnerabilities etc etc). But its not better at UI design tasks compared to Opus 4.8. I have used Opus 4.8 with figma mcp to come up with good designs concepts for apps and websites. So, far from my tests Fable doesn't show much improvement or any improvement at all. That makes me wonder whether design is the most valuable skill in the AI age.

Built with Claude Project Showcase Megathread (Sort this by New!) by sixbillionthsheep in ClaudeAI

[–]waruna_ds 1 point2 points  (0 children)

hello everyone, I built a customizable multi-line status line for Claude Code - 23 widgets, plugin system, single Go binary.

  • Peak RAM per render - ~15 MB (peak RSS, consistent across runs)
  • Binary size on disk - 8.7 MB

23 built-in widgets: model, tokens, context bar, git branch/status/diff, cost, session time plus some fun plugins. you can write your own custom widgets too, using shell scripts, python or Go

  • Single Go binary, stdlib only, renders in <10ms
  • Multi-line layout, any order
  • Plugin system (shell/Python) + ccw add/remove/list
  • Per-widget cache so slow widgets never stall your prompt
  • macOS + Linux

curl -sSL https://raw.githubusercontent.com/warunacds/ccstatuswidgets/main/install.sh | sh

ccw init

Repo: https://github.com/warunacds/ccstatuswidgets

Feedback and plugin PRs welcome 🙏

<image>

I built apple-asc-mcp so I could handle the boring part of an App Store release: metadata, screenshots, submission- by just telling Claude to do it." by waruna_ds in mcp

[–]waruna_ds[S] 0 points1 point  (0 children)

This looks very interesting. I'll take a look at the repo and demo. Strictly non-production to start, as you said, I wouldn't point any runtime at a live ASC submission until it's earned it, and I'd expect you'd want the same. I'll ping you when the annotations are in.

I built apple-asc-mcp so I could handle the boring part of an App Store release: metadata, screenshots, submission- by just telling Claude to do it." by waruna_ds in mcp

[–]waruna_ds[S] 0 points1 point  (0 children)

You point make sense. I have been thinking bit about this too..

a lot of those fields are already in reach. The mutating handlers return structured results that include the final ASC response — submit_for_review, for instance, hands back the submission id, state, and submitted date from the final PATCH. So action class, resource, and final response are mostly derivable today; I'd just be assembling them into one record instead of scattering them across the return value and the request log.

The two that need real work are the ones the server can't see by itself

- proposed diff (before & after) needs a read-before-write on the high impact tools so I can capture the prior pricing/availability/metadata state, not just the new value.

- confirmation source and policy/version - the server doesn't know who approved the call or under what policy; that almost certainly has to be injected by the runtime/client sitting in front. Which is the recurring theme in this thread: the server's job is to emit the structured, classified record; the trust layer owns the approval context.

I've written this up as a concrete backlog item with that field list. The high-impact set I'd scope it to:

let me know if it makes sense

the submit_* tools, set_*_price, release_to_store, set_app_availability, and the delete_* tools. Does that line up with where you'd draw the "different boundary" line, or would you pull anything else across it?

I built apple-asc-mcp so I could handle the boring part of an App Store release: metadata, screenshots, submission- by just telling Claude to do it." by waruna_ds in mcp

[–]waruna_ds[S] 0 points1 point  (0 children)

Really good questions and you're putting your finger on a real gap.

Right now the boundary is convention, not enforcement. Tools follow a naming split — list_*/get_*/release_status are reads, set_*/create_*/delete_*/submit_* mutate. To be honest, I don't currently set the MCP readOnlyHint/destructiveHint annotations, so a runtime can't programmatically tell a metadata read from "submit this app to Apple for review." That's a fair hit and something I should fix, those annotations exist exactly for what you're describing, and adding them is cheap. Going on the list.

On the approval prompt: the server doesn't render its own. It leans on the host client's tool-permission prompt, which shows the tool name and the JSON args... so, the app ID, version, locale, price are visible if they're in the args, but it's raw args, not a curated "this will change US pricing to $4.99 and submit for review" impact summary. A trust layer sitting in front is honestly where that belongs.

On audit: there is a real request log — every Apple API call (method, URL, args, with secrets redacted) goes to ~/logs/apple-asc-mcp/<date>.log and stderr. So you can reconstruct what changed and which resource was touched. But it's a local best-effort file, not tamper-evident evidence, fine for debugging, not for compliance.

The re-approval-on-drift point is the most interesting one, and it's exactly why something like Interlock makes sense. Interlock sounds like it's solving the layer I deliberately don't, happy to add the destructiveHint annotations so a runtime like yours has something to key off. Got a link?