完了とします。

確認しましたー。ありがとうございます。
早速Exampleで使っています。
とても良いです。GoodGood。

対処しました（r2899）。

あと、できれば、URLもあると良いです。
アノテーション内だとクラス指定(Redirect.to)が使えない場所もあるので、
URLの表現があるとそれを利用することができます。(例えば、reenterの指定など)

URL = "/member/search/input.html";

議論結果、実装することに。
但し、微調整あり。

// xxx.member.edit.InputPageクラスだとして
PKG = "member.edit"
NAME = "input"

// プロパティ
P_memberName = "memberName"
P_memberAccount = "memberAccount"
...

// アクション
A_get = "_get"
A_post_confirm = "_post_confirm"
...

Stringのリテラルを極力タイプセーフにする感じですかね。良いと思います。何かの名前を変えた場合は定数名も変わり、その定数を参照している箇所はビルドエラーになるので、追従できていない箇所が分かりやすいと思います。

定義名ですが、もっと割り切って：

// xxx.member.edit.InputPageクラスだとして
PKG = "member.edit"
PAGE = "input"

// プロパティ
P_memberName = "memberName"
P_memberAccount = "memberAccount"
...

// アクション
A_get = "_get"
A_post_confirm = "_post_confirm"
...

って短くてもいいかもです。
やはり、バリデータを記述するとき、大量に使うので見やすい方がいいため。

> Conversationだけでなく、バリデーションなどアクションやプロパティを
> アノテーション内で指定することは多いと思われ
ちょうど、Exampleでバリデーションを実装していたのですが、
バリデーションのときこそ、この定義がないとつらいと感じました。

まとめると、以下のようなイメージ：
(定義名は仮。Ymirのポリシー次第)

// xxx.member.edit.InputPageクラスだとして
PKG = "member.edit"
PAGE = "input"

// プロパティ
PROP_memberName = "memberName"
PROP_memberAccount = "memberAccount"
...

// アクション
ACT_get = "_get"
ACT_post_confirm = "_post_confirm"
...

プロパティ名やアクション名だけでなく、「パッケージ名」や
「Pageクラスのプロパティ名」などあると良さそうです。

@Conversation(name = "edit", phase = "input", followAfter = { "list", "confirm" })
public class InputPage extends InputPageBase {

というConversation定義が

@Conversation(name = PKG, phase = PAGE, followAfter = { ListPage.PAGE, ListPage.PAGE })

のようになります。

実際にはConversationは自由度の高いものであり、
必ずしも上記のように綺麗にPage構造と一致するわけではありませんが、
上記のようにフィットすることも多いかと思いますので、
「使う使わないかはユーザの自由」ということでとりあえず定義だけでもあると
良いのではないかと考えました。

> StringのStaticFinalでなく、独自のクラスの定義にしてもいいかも。
これに関しては、Conversationの場合はString型の属性に「actionName」と
「Name」と付いていて都合が良いが、@Requiredや@Lengthなど別の
アノテーションはこの辺の都合が良くないので、独自のクラスでの
互換性を保つことを前提とすると追加はややこしそうなので忘れて下さい。