Oceans of Wisdom

and then we need to make the deployment bus/train/etc

and we will tell the agents to use those

take a look and make whatever adjustments you want

i put a deployment skill in FE and BE for agents

if that is not correct let me know

I did not put @[ragne] in on the backend bc I think she does not do any work there?

merge rule added to BE

life is safe again

rogue agent had stopped itself

when are we going to be ready to actually deploy auth v2

while FBI is investigating

i have asked it to investigate what happened

no, no, I don't see anything running tbh

is this what they call Recursive Self Improvement? :slightly_smiling_face:

never seen anything pick up a draft

i am really surprised

let me find it

yo i am back

lol

Anyway go forward!

Anyway go forward!

In a couple of hours

Will see!

you want me to go BE = 1a-staging FE = main Then BE = main

so lets say we are doing a combo FE BE feature

or did you mean it should be on your branch 1a?

it is BE?

why not?

lol

and deployed to staging?

if it is on staging, haven't you merged?

what is the commit that I need to avoid deploying :slightly_smiling_face:

now question: I can still deploy to prod without deploying this right?

of course the button can and should stay on 'share' regardless

we should just have an upgrade button

re the sharing, this is what I mean, we should not 'hack' our way to them finding the upgrade button

we should not log them out

people may be away from their device that they use to log in

I think 30 days is ok for all

and we probably need a page explaining all of this

30 days or something?

and how long will we give you to upgrade?

shouldn't we just have an upgrade button active until you upgrade

that you need to realize that the share button triggers the upgrade?

last bullet seems a bit counter-intuitive

should be ok to start but we can see later

yes this is what you need to do - run it on different ports; this is where you start getting into large RAM needs

this way we can override as needed but any random PR that comes in needs one of us to approve

@[prxt0] / all, take a look and try, I think this is the right way to do it

Set up in GitHub. Created team `6529seize Maintainers` / `6529seize-maintainers` with repo permission `maintain` on `6529-Collections/6529seize-frontend`. Members active: `punk6529`, `ragnep`, `GelatoGenesis`, `simo6529`, `prxt6529` Effective repo roles verified: `punk6529`: `admin`, unchanged `GelatoGenesis`: `admin`, unchanged `ragnep`: `maintain` `simo6529`: `maintain` `prxt6529`: `maintain` Also replaced the old `main` branch protection with an active repository ruleset: `main maintainer review and merge policy` Ruleset ID: `18018081` It applies to the default branch and enforces: - PR required before merging - 1 approval required - approval must come from `6529seize Maintainers` - stale approvals dismissed on push - last pusher approval protection - review threads must be resolved - required checks preserved: `DCO`, `security/snyk (6529)` - no direct updates to `main` except via PR-only bypass - no deletes / force pushes The maintainer team has **PR-only bypass**, matching GitHub’s intended ruleset model: they can override and merge through a PR, while non-maintainers need one of them involved.