docs(design): add shared work queue ADR and update persona references

[ldpliu]

Summary

• Add ADR-0003: file-based JSONL shared work queue with san queue subcommand (EN + CN)
• Replace all san agent run --persona references with san --persona <name> -p in ADR-0002
• Update ADR-0002 implementation plan to reflect completed PR fix(app): make --persona take effect in -p print mode #231 (print mode persona fix)

Test plan

• Docs only — no code changes
• Both EN and CN versions aligned

🤖 Generated with Claude Code

[ldpliu]

/cc @yanmxa

[yanmxa]

@ldpliu This one looks good content-wise, but the branch has fallen behind main. Could you rebase onto the latest main (or click "Update branch")? Once it's fresh and CI is green we can merge. Thanks! 🙏

[ldpliu]

@yanmxa done

[yanmxa]

I'd like to keep the file not linked, how about using the settings.json to maintain the team/member

[ldpliu]

Which settings.json are you referring to? The per-persona settings.json inside each persona directory (e.g., san-team/leader/settings.json), or San's own ~/.san/settings.json?

If the idea is to maintain a team/member mapping inside settings.json, it would be quite difficult to configure in practice. Teams is currently a virtual concept — it's not a runtime entity in San. The san-team repo is just a directory structure that holds persona configurations. San only recognizes --persona at startup; there's no --team flag and no team abstraction to resolve.

So it's hard to use a settings.json-based team/member config to launch different persona roles.

Right now persona loading only looks in two places (see internal/persona/persona.go):

1. ~/.san/personas// — user level
2. .san/personas// — project level (higher priority)

You either place the persona directory directly under one of these paths, or symlink it there. No other loading paths exist. The symlink approach isn't the most elegant, but it's simple and direct — no extra team abstraction layer needed.

Given these constraints, do you see a better alternative?