top only images is ok for now
Shit Punk Says
Oceans of Wisdom
19,158
matching drops
#1459158
2026-09-22 15:17
nothing is full auto (yet), but will be ofc
If I created an issue in the repo (I did), Will your agent auto-review it ?
sweet
Yes. I was fortunate to bid and win a 1/1 auction of @[baiwei].
so still on a leash
but yes this is doable what you described
bc I have not yet hardened it for prompt injection etc
not yet, it only chats on specific topics in specific chat with pre-authorization from me
Is this auto-detecting issues from chats and creating PRs ?
wtf lol
impressive!
ha!
good!
2. I read cuttle’s summary of how punk is deploying and I had claude go in and steal the deployment strategy
you are always playing a game of some type. it is just usually you are playing the rules of some dead person's game that you have not realized you are planning
better to think about what you want and play that game
Didn’t ask for this but: “What I think you’d find most interesting
This article is weirdly aligned with what you’ve been building around 6529.
TDH, REP, Meme Cards, Key Holders, the bar, Anon Wave—whether intentionally or not, you’ve been creating a game layer on top of community life.
The article’s deepest point isn’t productivity.
It’s that humans need:
* a story,
* a direction,
* feedback loops,
* status systems,
* and meaningful games.
When those don’t exist, people drift.
When they do exist, people will eat glass for them.”
nothing escapes the all-seeing eye of 6529!
😂😂😂 Yes, I remember, I'll show you now... GIANT#16 in 2022
every cycle there is someone who reinvents the idea of buying a ton of BTC with high leverage
belief in a story shifts wen the pillars underpinning the story change
was 'there is no second best'
now 'ok there's a STRC ticker that's almost as good as BTC'
was 'never sell your bitcoin'
now 'ok I'm selling some of my bitcoin'
if a pillar is fundamental... then destroying it destroys the story...and that's the end of the perceived value / willingness to pay. Google 'Ratner + gold' story in the UK. One of many...
this is SICK
i expect i'd only sell 2-3 of these but i think i'd make it my entire wardrobe
ok tech starting to move in the right direction; infinity more to do
I am not sure about #3 -> I think we need a discovery part of the left bar and it can't be deep off the fold
tech feedback items i am dealing with. please do not take these items, i am doing these
I tested against the production-backed local app. I did not post, vote, react, add REP, or edit anything.
**Tested Findings**
1. **Discover black page/API failure**
- Tested `/discover` with Balanced, Score, Hot, and REP filters.
- Status: **fixed / not reproduced**.
- Saw real production waves and no black screen.
- Improve: long wave descriptions make cards tall. Truncate card text or add a cleaner compact mode.
2. **DM sorting confusion**
- Tested `/messages`.
- Status: **not fixed**.
- The list is split into “Following waves” and “All quality-ranked waves list,” but those labels are not visible to users.
- Fix: show clear section labels or add the same `All / Joined` selector as Waves, while keeping newest-first ordering inside each section.
3. **Highly Rated block above Pinned/Following**
- Tested `/waves`.
- Status: **not fixed**.
- Highly Rated still appears near the top, above Pinned/Following, and includes waves the user may not care about.
- Fix: move it below Pinned/Following, collapse it by default, or label it as “Suggested.”
4. **All / Joined switch on Waves**
- Tested `/waves`.
- Status: **not fixed**.
- Clicking `Joined` and `All` changed the button state, but the wave list did not meaningfully change.
- Fix: wire the filter properly or remove/disable it until it works.
5. **Subwaves are hard to find**
- Tested `Follow The Repo` on `/waves`.
- Status: **partly fixed**.
- Expanding `Follow The Repo` shows `6529 Tech Feedback` with recent activity.
- Still bad: when parent is collapsed, active subwaves are hidden.
- Fix: show active subwave preview/count on the parent row, or auto-expand parent when a subwave has fresh activity.
6. **Wave row click area**
- Tested `/waves`.
- Status: **not fixed**.
- Clicking empty space inside a highlighted row does nothing. Clicking the title opens the wave.
- Fix: make the full row clickable, while keeping buttons like expand/pin separate.
7. **Reply action**
- Tested Tech Feedback on desktop and phone-sized browser viewport.
- Status: **not fixed in my browser test**.
- Reply icons were visible, but clicking them did not show a reply target and did not focus the composer.
- Fix: check the drop action click handler/state path. Add a visible reply chip above composer after click, plus an E2E test.
8. **REP category rankings**
- Tested `/simo` and `/rep/categories/6529%20Dev%20Team`.
- Status: **fixed / implemented**.
- Category panel and full page show totals, recipients, givers, pairings, and recent activity.
- Improve: make category rows look more obviously clickable, and make “Open full page” more prominent.
9. **Profile “Show all waves” / wave preview**
- Tested `/simo/brain`.
- Status: **partly fixed**.
- The count button opens a list of created waves.
- Still confusing: visible button text is just `15`; accessible label says “View all created waves,” but users only see the number.
- Fix: use visible text like `Show all 15 created waves`, then change to `Hide created waves`.
10. **Score / Hot / REP badges**
- Tested Discover cards and Tech Feedback header.
- Status: **usable, but still visually busy**.
- Wave header is better: one `Score 94` chip with detailed score info in the accessible label.
- Discover cards still show many metrics at once.
- Fix: show one main score by default; move Hot/REP detail into tooltip/details.
11. **API usage metric suggestion**
- Tested `/tools/api` and `/network/health`.
- Status: **not implemented / not visible**.
- I did not see API hit counts or usage metrics.
- Fix: add a small API usage panel on API docs/status/metrics page, if the data is safe to expose.
**Not Fully Tested**
12. **Poll permissions in REP-gated/view-only waves**
- Not tested.
- Reason: needs a low/no-REP account and would require voting or attempting to vote in production.
- Fix direction: enforce permission server-side, disable vote UI client-side, and add permission tests.
13. **Real mobile reply issue**
- Partly tested with phone-sized browser only.
- Not tested on real phone/app.
- Since browser reply also failed, this still needs attention.
14. **Phone app speed**
- Not tested.
- Reason: needs real device/network timing or RUM data.
- This was positive feedback, not a current bug.
15. **Video player**
- Not fully tested on production.
- Home page had no visible video element, and I did not hunt for a known video drop.
- Needs a known video drop or real-device media test.
how much RAM do you have?
more on AUTH
- its very close, i just keep testing and iterating
- i needs soo much RAM in order to have codex running + web locally which is becoming a bottleneck especially in cases like today where i had to also build Desktop app a few times
- BE PR: https://github.com/6529-Collections/6529seize-backend/pull/1616
- FE PR: https://github.com/6529-Collections/6529seize-frontend/pull/2556
- details release plan with legacy migration steps: https://github.com/6529-Collections/6529seize-backend/blob/codex/wallet-security-hardening/docs/auth/session-v2-migration-plan.md
What device?
9/ the SAFE apps (staging and prod) are each in separate accounts already; as are IPFS and Arweave but we will need to organize, do cutovers etc
8/ discussion review of segregated AWS accounts will be weekend topic
7/ maybe will get to the better deployment process today tbd
6/ also doing some hardening on expected specs, behavior, etc of subwaves
5/ also trying to make responsivness bot more useful
4/ going to be very AFK during most of the day today so will try to get the above out and then be back more aggressively over the weekend I expect
3/ also have a bot handling a bunch of the small PRs to merge and deploy
2/ similarly have first draft SAFE app up, ugly AF, so fixing :slightly_smiling_face:
1/ pushed very basic CMS last night for profiles; tons to do there, nothing needed from anyone, just FYI
gm
https://6529.io/waves/49f0e595-ec7c-4235-8695-a527f61b69f4
This is currently the best place to "follow the repo"
You need to expand it and there are 5 subwaves
- PR Firehose: all the PRs, all the repos
- 6529 Tech Feedback: give your ideas here, we will monitor (the prior wave, now a subwave)
- 6529 Releases: the prior wave now a subwave (subscriptions, pins, kept)
- PR Summaries: every 4 hours, a summary
- Dev Team Chat: us talking among ourselves more technical, you can read
It is not 100% there yet, but I think 80% there, we are getting there, in terms of this being the right wave structure
subwave
or subwve as the case may be
the preference is this wave
the idea being that we consolidate all the tech items in one place
it is now a subwave of follow the repo
p.p.s. why doesn't this wave show up in my joined waves sidebar? i'm a member. 🤔
ideally quorum stuff gets here too
and we will pick it up
no please post here
ok one more question - when multiple agents need to check their staging / main deployment on a single deployment and iterate until it is fixed, how does this work - when it is 1 agent per deployment, it can iterate solo until it works
Yes, agreed. If the previous bus finishes and there is already something ready to deploy, start the next iteration immediately.
The 30 minute number should be a max batching window / departure cadence, not a forced delay after the lane is free.
Better wording:
- If lane is free and queue has items: close the next bus now and deploy it.
- If lane is busy: collect items while it is busy.
- If lane stays busy a long time: the next bus is already closed/frozen before the lane frees, so it can depart immediately after the current bus completes.
- If lane is free and queue is empty: do nothing until a deploy request arrives, then deploy immediately.
So there is no idle waiting. The bus prevents endless resetting while a lane is busy; it should not add delay when a lane is open.
ok given the staging and production deployment times of this repo, how often should the bus depart
Yes. I would make the bus deterministic, with a cutoff, not a sliding window.
Concrete model:
1. If prod lane is idle and queue is empty: deploy immediately. No artificial delay.
2. If prod/staging lane is busy, new merged PRs join the next bus.
3. A bus has states:
- Boarding: collecting eligible main commits / PRs.
- Closed: no more commits accepted.
- Staging: deploy exact closed SHA to staging.
- Validating: run smoke/e2e for that exact SHA.
- Prod: promote the same SHA to prod.
- Done or Failed.
4. The bus closes by rule, not vibes. Example rule:
- close at `lane becomes free + 2 minutes`, or
- close at `first queued PR + 10 minutes`, whichever comes first.
5. Once Closed, the SHA is frozen. Any commit that lands after that missed the bus and goes to the next bus. No resetting the bus because something new merged.
6. A release owner can mark one PR as urgent/hotfix. That bypasses batching only if it is safe and there is no active prod deploy. Otherwise it becomes the next bus with priority.
So scenario A gets immediate deploy. Scenario B gets batching, but with a hard departure time and exact SHA, so the bus cannot wait forever.
so can you get specific about how you would do it? we have two scenarios:
a) less common, nothing is actually queued, obviously we should not delay someones deployment in that case
b) more common it is busy, we should run a bus, but even in that case, we need to not have the permanently not leaving bus where it gets getting reset. so there should be a time when commits have missed the bus
Agreed. I would separate the fixes into two layers:
1. Immediate safety rail, now in flight: prod only from `main`, no overlapping prod deploys, exact SHA recorded.
2. Deployment bus / aggregator, next: collect compatible merged PRs into a timed or owner-approved release batch, deploy staging once for the batch, then promote that exact main SHA to prod.
I will treat the deployment bus as a separate follow-up workstream/spec rather than trying to hide it inside this incident fix PR.
not yet, still has some intervention by me
... The updated deploy skill is moving in that direction....
its self envolving?
re the non-main deployment but also why it did not crash everything
@[simo] @[prxt0] @[GelatoGenesis] pls see above
but soon, days, not weeks, will have to make the deployment bus
in the meantime, we should try, as possible to aggregate items into fewer deployments
that gathers all the commit and in any case deploys every X minutes
so we will need to have an aggregator
the problem will be when they are 20-30, you end up needing several hours to deploy
it is ok